Microservices Resources

DZone's Featured Microservices Resources

Scaling Java Microservices to Extreme Performance Using NCache

By Gowtham K

Microservices have emerged as a transformative architectural approach in the realm of software development, offering a paradigm shift from monolithic structures to a more modular and scalable system. At its core, microservices involve breaking down complex applications into smaller, independently deployable services that communicate seamlessly, fostering agility, flexibility, and ease of maintenance. This decentralized approach allows developers to focus on specific functionalities, enabling rapid development, continuous integration, and efficient scaling to meet the demands of modern, dynamic business environments. As organizations increasingly embrace the benefits of microservices, this article explores the key principles, advantages, and challenges associated with this architectural style, shedding light on its pivotal role in shaping the future of software design and deployment. A fundamental characteristic of microservices applications is the ability to design, develop, and deploy each microservice independently, utilizing diverse technology stacks. Each microservice functions as a self-contained, autonomous application with its own dedicated persistent storage, whether it be a relational database, a NoSQL DB, or even a legacy file storage system. This autonomy enables individual microservices to scale independently, facilitating seamless real-time infrastructure adjustments and enhancing overall manageability. NCache Caching Layer in Microservice Architecture In scenarios where application transactions surge, bottlenecks may persist, especially in architectures where microservices store data in non-scalable relational databases. Simply deploying additional instances of the microservice doesn't alleviate the problem. To address these challenges, consider integrating NCache as a distributed cache at the caching layer between microservices and datastores. NCache serves not only as a cache but also functions as a scalable in-memory publisher/subscriber messaging broker, facilitating asynchronous communication between microservices. Microservice Java application performance optimization can be achieved by the cache techniques like Cache item locking, grouping Cache data, Hibernate Caching, SQL Query, data structure, spring data cache technique pub-sub messaging, and many more with NCache. Please check the out-of-the-box features provided by NCache. Using NCache as Hibernate Second Level Java Cache Hibernate First-Level Cache The Hibernate first-level cache serves as a fundamental standalone (in-proc) cache linked to the Session object, limited to the current session. Nonetheless, a drawback of the first-level cache is its inability to share objects between different sessions. If the same object is required by multiple sessions, each triggers a database trip to load it, intensifying database traffic and exacerbating scalability issues. Furthermore, when the session concludes, all cached data is lost, necessitating a fresh fetch from the database upon the next retrieval. Hibernate Second-Level Cache For high-traffic Hibernate applications relying solely on the first-level cache, deployment in a web farm introduces challenges related to cache synchronization across servers. In a web farm setup, each node operates a web server—such as Apache, Oracle WebLogic, etc.—with multiple instances of httpd processes to serve requests. Each Hibernate first-level cache in these HTTP worker processes maintains a distinct version of the same data directly cached from the database, posing synchronization issues. This is why Hibernate offers a second-level cache with a provider model. The Hibernate second-level cache enables you to integrate third-party distributed (out-proc) caching providers to cache objects across sessions and servers. Unlike the first-level cache, the second-level cache is associated with the SessionFactory object and is accessible to the entire application, extending beyond a single session. Enabling the Hibernate second-level cache results in the coexistence of two caches: the first-level cache and the second-level cache. Hibernate endeavors to retrieve objects from the first-level cache first; if unsuccessful, it attempts to fetch them from the second-level cache. If both attempts fail, the objects are directly loaded from the database and cached. This configuration substantially reduces database traffic, as a significant portion of the data is served by the second-level distributed cache. NCache Java has implemented a Hibernate second-level caching provider by extending org.hibernate.cache.CacheProvider. Integrating NCache Java Hibernate distributed caching provider with the Hibernate application requires no code changes. This integration enables you to scale your Hibernate application to multi-server configurations without the database becoming a bottleneck. NCache also delivers enterprise-level distributed caching features, including data size management, data synchronization across servers, and more. To incorporate the NCache Java Hibernate caching provider, a simple modification of your hibernate.cfg.xml and ncache.xml is all that is required. Thus, with the NCache Java Hibernate distributed cache provider, you can achieve linear scalability for your Hibernate applications seamlessly, requiring no alterations to your existing code. Code Snippet Java // Configure Hibernate properties programmatically Properties hibernateProperties = new Properties(); hibernateProperties.put("hibernate.connection.driver_class", "org.h2.Driver"); hibernateProperties.put("hibernate.connection.url", "jdbc:h2:mem:testdb"); hibernateProperties.put("hibernate.show_sql", "false"); hibernateProperties.put("hibernate.hbm2ddl.auto", "create-drop"); hibernateProperties.put("hibernate.cache.use_query_cache", "true"); hibernateProperties.put("hibernate.cache.use_second_level_cache", "true"); hibernateProperties.put("hibernate.cache.region.factory_class", "org.hibernate.cache.jcache.internal.JCacheRegionFactory"); hibernateProperties.put("hibernate.javax.cache.provider", "com.alachisoft.ncache.hibernate.jcache.HibernateNCacheCachingProvider"); // Set other Hibernate properties as needed Configuration configuration = new Configuration() .setProperties(hibernateProperties).addAnnotatedClass(Product.class); Logger.getLogger("org.hibernate").setLevel(Level.OFF); // Build the ServiceRegistry ServiceRegistry serviceRegistry = new StandardServiceRegistryBuilder() .applySettings(configuration.getProperties()).build(); // Build the SessionFactory SessionFactory factory = configuration.buildSessionFactory(serviceRegistry); // Create a List of Product objects ArrayList<Product> products = (ArrayList<Product>) getProducts(); // Open a new Hibernate session to save products to the database. This also caches it try (Session session = factory.openSession()) { Transaction transaction = session.beginTransaction(); // save() method saves products to the database and caches it too System.out.println("ProductID, Name, Price, Category"); for (Product product : products) { System.out.println("- " + product.getProductID() + ", " + product.getName() + ", " + product.getPrice() + ", " + product.getCategory()); session.save(product); } transaction.commit(); System.out.println(); // Now open a new session to fetch products from the DB. // But, these products are actually fetched from the cache try (Session session = factory.openSession()) { List<Product> productList = (List<Product>) session.createQuery("from Product").list(); if (productList != null) { printProductDetails(productList); } } Integrate NCache with Hibernate to effortlessly cache the results of queries. When these objects are subsequently fetched by Hibernate, they are retrieved from the cache, thereby avoiding a costly trip to the database. From the above code sample, the products are saved in the database, and it also caches; now, when the new session opens to fetch the product details, it will fetch from the Cache and avoid an unnecessary database trip. Learn more about Hibernate Caching Scaling With NCache Pub/Sub Messaging NCache is a distributed in-memory caching solution designed for .NET. Its compatibility extends to Java through a native client and third-party integrations, ensuring seamless support for both platforms. NCache serves as an in-memory distributed data store tailored for .NET and Java, offering a feature-rich, in-memory pub/sub mechanism for event-driven communication. This makes it straightforward to set up NCache as a messaging broker, employing the Pub/Sub model for seamless asynchronous communication between microservices. Using NCache In-Memory Pub/Sub for Microservices NCache enables Pub/Sub functionality by establishing a topic where microservices can publish and subscribe to events. These events are published to the NCache message broker outside the microservice. Within each subscribing microservice, there exists an event handler to manage the corresponding event once it has been published by the originating microservice. In the realm of Java microservices, NCache functions as an event bus or message broker, facilitating the relay of messages to one or multiple subscribers. In the context of Pub/Sub models that necessitate a communication channel, NCache serves as a medium for topics. This entails the publisher dispatching messages to the designated topic and subscribers receiving notifications through the same topic. Employing NCache as the medium for topics promotes loose coupling within the model, offering enhanced abstraction and additional advantages for distributed topics. Publish The code snippet below initializes the messageService object using NCache MessagingService package. Initializing the Topic Java // Create a Topic in NCache. MessagingService messagingService = cache.getMessagingService(); Topic topic = messagingService.createTopic(topicName); // Create a thread pool for publishers ExecutorService publisherThreadPool = Executors.newFixedThreadPool(2); The below code snippet used to define register the subscribers to this topic Register subscribers to this Topic MessageReceivedListener subscriptionListener1 = new MessageReceivedListener() { @Override public void onMessageReceived(Object o, MessageEventArgs messageEventArgs) { messageReceivedSubscription1(messageEventArgs.getMessage()); } }; MessageReceivedListener subscriptionListener2 = new MessageReceivedListener() { @Override public void onMessageReceived(Object o, MessageEventArgs messageEventArgs) { messageReceivedSubscription2(messageEventArgs.getMessage()); } }; TopicSubscription subscription1 = topic.createSubscription(subscriptionListener1); TopicSubscription subscription2 = topic.createSubscription(subscriptionListener2); NCache provides two variants of durable subscriptions to cater to the message durability needs within your Java microservices: Shared Durable Subscriptions: This allows multiple subscribers to connect to a single subscription. The Round Robin approach is employed to distribute messages among the various subscribers. Even if a subscriber exits the network, messages persistently flow between the active subscribers. Exclusive Durable Subscriptions: In this type, only one active subscriber is allowed on a subscription at any given time. No new subscriber requests are accepted for the same subscription until the existing connection is active. Learn more Pub/Sub Messaging with NCache implementation here Pub/Sub Messaging in Cache: An Overview SQL Query on Cache NCache provides your microservices with the capability to perform SQL-like queries on indexed cache data. This functionality becomes particularly beneficial when the values of the keys storing the desired information are not known. It abstracts much of the lower-level cache API calls, contributing to clearer and more maintainable application code. This feature is especially advantageous for individuals who find SQL-like commands more intuitive and comfortable to work with. NCache provides functionality for searching and removing cache data through queries similar to SQL's SELECT and DELETE statements. However, operations like INSERT and UPDATE are not available. For executing SELECT queries within the cache, NCache utilizes ExecuteReader; the ExecuteScalar function is used to carry out a query and retrieve the first row's first column from the resulting data set, disregarding any extra columns or rows. For NCache SQL queries to function, indexes must be established on all objects undergoing search. This can be achieved through two methods: configuring the cache or utilizing code with "Custom Attributes" to annotate object fields. When objects are added to the cache, this approach automatically creates indexes on the specified fields. Code Snippet Java String cacheName = "demoCache"; // Connect to the cache and return a cache handle Cache cache = CacheManager.getCache(cacheName); // Adds all the products to the cache. This automatically creates indexes on various // attributes of Product object by using "Custom Attributes". addSampleData(cache); // $VALUE$ keyword means the entire object instead of individual attributes that are also possible String sql = "SELECT $VALUE$ FROM com.alachisoft.ncache.samples.Product WHERE category IN (?, ?) AND price < ?"; QueryCommand sqlCommand = new QueryCommand(sql); List<String> catParamList = new ArrayList<>(Arrays.asList(("Electronics"), ("Stationery"))); sqlCommand.getParameters().put("category", catParamList); sqlCommand.getParameters().put("price", 2000); // ExecuteReader returns ICacheReader with the query resultset CacheReader resultSet = cache.getSearchService().executeReader(sqlCommand); List<Product> fetchedProducts = new ArrayList<>(); if (resultSet.getFieldCount() > 0) { while (resultSet.read()) { // getValue() with $VALUE$ keyword returns the entire object instead of just one column fetchedProducts.add(resultSet.getValue("$VALUE$", Product.class)); } } printProducts(fetchedProducts); Utilize SQL in NCache to perform queries on cached data by focusing on object attributes and Tags, rather than solely relying on keys. In this example, we utilize "Custom Attributes" to generate an index on the Product object. Learn more about SQL Query with NCache in Java Query Data in Cache Using SQL Read-Thru and Write-Thru Utilize the Data Source Providers feature of NCache to position it as the primary interface for data access within your microservices architecture. When a microservice needs data, it should first query the cache. If the data is present, the cache supplies it directly. Otherwise, the cache employs a read-thru handler to fetch the data from the datastore on behalf of the client, caches it, and then provides it to the microservice. In a similar fashion, for write operations (such as Add, Update, Delete), a microservice can perform these actions on the cache. The cache then automatically carries out the corresponding write operation on the datastore using a write-thru handler. Furthermore, you have the option to compel the cache to fetch data directly from the datastore, regardless of the presence of a possibly outdated version in the cache. This feature is essential when microservices require the most current information and complements the previously mentioned cache consistency strategies. The integration of the Data Source Provider feature not only simplifies your application code but also, when combined with NCache's database synchronization capabilities, ensures that the cache is consistently updated with fresh data for processing. ReadThruProvider For implementing Read-Through caching, it's necessary to create an implementation of the ReadThruProvider interface in Java Here's a code snippet to get started with implementing Read-Thru in your microservices: Java ReadThruOptions readThruOptions = new ReadThruOptions(ReadMode.ReadThru, _readThruProviderName); product = _cache.get(_productId, readThruOptions, Product.class); Read more about Read-Thru implementation here: Read-Through Provider Configuration and Implementation WriteThruProvider: For implementing Write-Through caching, it's necessary to create an implementation of the WriteThruProvider interface in Java The code snippet to get started with implementing Write-Thru in your microservices: Java _product = new Product(); WriteThruOptions writeThruOptions = new WriteThruOptions(WriteMode.WriteThru, _writeThruProviderName) CacheItem cacheItem= new CacheItem(_customer) _cache.insert(_product.getProductID(), cacheItem, writeThruOptions); Read more about Write-Thru implementation here: Write-Through Provider Configuration and Implementation Summary Microservices are designed to be autonomous, enabling independent development, testing, and deployment from other microservices. While microservices provide benefits in scalability and rapid development cycles, some components of the application stack can present challenges. One such challenge is the use of relational databases, which may not support the necessary scale-out to handle growing loads. This is where a distributed caching solution like NCache becomes valuable. In this article, we have seen the variety of ready-to-use features like pub/sub messaging, data caching, SQL Query, Read-Thru and Write-Thru, and Hibernate second-level Java Cache techniques offered by NCache that simplify and streamline the integration of data caching into your microservices application, making it an effortless and natural extension. More

Implementation Best Practices: Microservice API With Spring Boot

By Amritendu De

Technical Architecture First, let's turn to the architecture, which will be explained in detail. Let's look at each of these tiers in detail. Let me explain the architecture in detail. These components are commonly associated with the architecture of applications that follow the principles of Domain-Driven Design (DDD) and Model-View-Controller (MVC) or similar architectural patterns. Let me cover this one by one: Entities Entities represent the core business objects or concepts in your application. They encapsulate data related to the business domain. For example, in an Employee Management System, an employee entity might have attributes like name, email, and salary related to an employee. Repositories Repositories are responsible for handling the data access logic. They provide an abstraction over the data storage, allowing the application to interact with the data without worrying about the underlying storage details. For example, an EmployeeRepository would handle operations like storing, retrieving, updating, and deleting employee records in the database. Services Services contain business logic that doesn't naturally fit within the methods of an entity. They orchestrate interactions between entities and repositories to fulfill higher-level use cases. For example, an EmployeeService might have methods to calculate bonuses, process employee transfers, or handle complex business rules involving multiple entities. Mappers Mappers are responsible for transforming data between different layers of the application. They convert data from database entities to domain objects and vice versa. For example, an EmployeeMapper might convert an Employee entity to a data transfer object (EmployeeRequest) that can be sent over the network or used by the presentation layer. Controllers Controllers handle incoming requests from the user interface or external systems. They interpret user input, invoke the necessary services or business logic, and prepare the response to be sent back. In a web application, a controller receives an HTTP request, extracts the necessary data, and delegates the request to the appropriate service. It then formats the service response and sends it back to the client. Frontend: You have the option of building Native Apps like Android and iOS. Desktop browser apps or mobile browser apps can be built using React or Angular frameworks. Best Practices for Implementation of the Architecture Entity: Useful Tips Name the package as “entities” under the feature name Set id as Long and generation type as identity Name the class and table in plurals like users Use Lombok for constructor and getter/setter code Have a length for every String field Set nullable to either true/false Use references to other tables like @ManyToOne. Remember, the table created is automatic, and what you write in the entity matters. Use @OneToMany bidirectional if you wish to save the values in multiple tables in one call. Use @ManyToMany to join tables. Create a separate Join class if there are fields in the join table apart from join id columns. Identify the right inheritance type for is-a relationship. Pick between single table, class table, and concrete table inheritance based on the number of fields in every class. Example Java package org.project.feature.entities; import jakarta.persistence.*; import lombok.AllArgsConstructor; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.Setter; @Getter @Setter @NoArgsConstructor @AllArgsConstructor @Entity @Table(name = "users") public class Users { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(length = 100, nullable = false) private String firstName; @Column(length = 100, nullable = false) private String lastName; @Column(length = 100, nullable = false, unique = true) private String email; } Repository: Useful Tips Name the package as “repositories” under the feature name Extend the JpaRepository with the entity name and id as Long As much as possible, use the style as a method for querying the entity like findByEmail Use batch operations for multiple entries to the database, like saveAll Use Optional for the return type as much as possible Example Java package org.project.feature.repositories; import org.project.feature.entities.Users; import org.springframework.data.jpa.repository.JpaRepository; public interface UsersRepository extends JpaRepository<Users, Long> { } Service: Useful Tips Name the package as “services” under the feature name Create an interface for all the operations within the service and create an implementation class Use @AllArgsConstructor for @Autowired annotation Accept the Request object and return the Response object from the model’s package. If multiple repositories need to be called, it should be called in a transaction unless you wish to start a new transaction. If you wish to call multiple services, the particular service has to be named as an aggregate service and within a transaction. Do not return the ResponseEntity from the service; it is the job of the controller tier. Example Java package org.project.feature.services; import org.project.feature.models.UsersRequest; import org.project.feature.models.UsersResponse; import java.util.List; public interface UsersService { UsersResponse createUser(UsersRequest usersRequest); UsersResponse getUserById(Long userId); List<UsersResponse> getAllUsers(); UsersResponse updateUser(Long id, UsersRequest users); void deleteUser(Long userId); } Java package org.project.feature.services.impl; import lombok.AllArgsConstructor; import org.project.feature.entities.Users; import org.project.feature.mappers.UsersMapper; import org.project.feature.models.UsersRequest; import org.project.feature.models.UsersResponse; import org.project.feature.repositories.UsersRepository; import org.project.feature.services.UsersService; import org.springframework.stereotype.Service; import java.util.ArrayList; import java.util.List; import java.util.Optional; @Service @AllArgsConstructor public class UsersServiceImpl implements UsersService { private final UsersRepository usersRepository; private final UsersMapper usersMapper; @Override public UsersResponse createUser(UsersRequest usersRequest) { Users users = usersMapper.convertRequestToEntity(usersRequest); Users saved = usersRepository.save(users); return usersMapper.convertEntityToResponse(saved); } @Override public UsersResponse getUserById(Long userId) { Optional<Users> optionalUser = usersRepository.findById(userId); return usersMapper.convertEntityToResponse(optionalUser.get()); } @Override public List<UsersResponse> getAllUsers() { List<Users> users = usersRepository.findAll(); List<UsersResponse> usersResponses = new ArrayList<>(); for (Users user : users) usersResponses.add(usersMapper.convertEntityToResponse(user)); return usersResponses; } @Override public UsersResponse updateUser(Long id, UsersRequest usersRequest) { Optional<Users> user = usersRepository.findById(id); Users existingUsers = user.orElse(null); existingUsers.setFirstName(usersRequest.getFirstName()); existingUsers.setLastName(usersRequest.getLastName()); existingUsers.setEmail(usersRequest.getEmail()); Users updatedUsers = usersRepository.save(existingUsers); return usersMapper.convertEntityToResponse(updatedUsers); } @Override public void deleteUser(Long userId) { usersRepository.deleteById(userId); } } Mappers: Useful Tips Name the package as “mappers” under the feature name Create an interface called Mapper using Generics and convert the entity to a model and vice versa using this mapper Do not use the entity as a return object in the controller tier Example Java package org.project.feature.mappers; import org.project.feature.entities.Users; import org.project.feature.models.UsersRequest; import org.project.feature.models.UsersResponse; import org.springframework.stereotype.Component; @Component public class UsersMapper { public UsersResponse convertEntityToResponse(Users users) { UsersResponse usersResponse = new UsersResponse(); usersResponse.setId(users.getId()); usersResponse.setFirstName(users.getFirstName()); usersResponse.setLastName(users.getLastName()); usersResponse.setEmail(users.getEmail()); return usersResponse; } public Users convertRequestToEntity(UsersRequest usersRequest) { Users users = new Users(); users.setFirstName(usersRequest.getFirstName()); users.setLastName(usersRequest.getLastName()); users.setEmail(usersRequest.getEmail()); return users; } } Model: Useful Tips Name the package as “models” under the feature name All requests and response objects will be stored here Use @Data annotation for the model classes The model should act as a frontend for the API, and the service should convert the model to an entity for talking to the repository. Example Java package org.project.feature.models; import jakarta.persistence.Column; import lombok.Data; import java.io.Serializable; @Data public class UsersRequest implements Serializable { private String firstName; private String lastName; private String email; } Java package org.project.feature.models; import jakarta.persistence.Column; import lombok.Data; import java.io.Serializable; @Data public class UsersResponse implements Serializable { private Long id; private String firstName; private String lastName; private String email; } Controller: Useful Tips Name the package as “controllers” under the feature name Try to create an API for every resource under a bounded context Make the resource names in plural, like /API/users For CRUD Operations: Use HTTP POST for create an operation with Request as the body Use HTTP PUT for update operation Use HTTP GET for retrieve all records Use HTTP GET with /{id} for retrieve with an identifier Use HTTP DELETE with /{id} to delete the record For operation other, the CRUD try avoiding a verb as much as possible Implement error handling at the controller tier Implement validation at the controller tier with @Valid Realize the difference between API thinking and RPC thinking. It is key to understanding APIs. Example Java package org.project.feature.controllers; import lombok.AllArgsConstructor; import org.project.feature.models.UsersRequest; import org.project.feature.models.UsersResponse; import org.project.feature.services.UsersService; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; import java.util.List; @RestController @AllArgsConstructor @RequestMapping("/api/users") public class UsersController { private final UsersService usersService; @PostMapping public ResponseEntity<UsersResponse> createUser(@RequestBody UsersRequest usersRequest){ UsersResponse savedUsers = usersService.createUser(usersRequest); return new ResponseEntity<>(savedUsers, HttpStatus.CREATED); } @GetMapping("{id}") public ResponseEntity<UsersResponse> getUserById(@PathVariable("id") Long userId){ UsersResponse users = usersService.getUserById(userId); return new ResponseEntity<>(users, HttpStatus.OK); } @GetMapping public ResponseEntity<List<UsersResponse>> getAllUsers(){ List<UsersResponse> users = usersService.getAllUsers(); return new ResponseEntity<>(users, HttpStatus.OK); } @PutMapping("{id}") public ResponseEntity<UsersResponse> updateUser(@PathVariable("id") Long userId, @RequestBody UsersRequest usersRequest){ UsersResponse updatedUsers = usersService.updateUser(userId, usersRequest); return new ResponseEntity<>(updatedUsers, HttpStatus.OK); } @DeleteMapping("{id}") public ResponseEntity<String> deleteUser(@PathVariable("id") Long userId){ usersService.deleteUser(userId); return new ResponseEntity<>("User successfully deleted!", HttpStatus.OK); } } Conclusion In a long-term vision, as and when the code base becomes bulky, you might need to use the Strangler pattern to take out some of the services and deploy them as a separate microservice. This kind of coding structure will help then. If you get your basics right from the very beginning, then later on, the ride will be smooth. More

An Approach To Synthetic Transactions With Spring Microservices: Validating Features and Upgrades

By Amol Gote

CORE

Modern gRPC Microservices: REST Gateways, Part 2

By Sriram Panyam

Navigating the Maze: A Comprehensive Guide To Selecting the Right Messaging Queue

By Phani Kumar Varma Kokkerlapati

Event-Driven Architecture for Software Development: Leverage the Strength of Reactive Systems

As a software developer, tightly coupled, monolithic applications can make you feel bogged down. Enter Event-Driven Architecture (EDA), a promising addition to the world of software development. This paradigm is all about events: changes in your system that trigger actions in other parts, leading to reactive, loosely coupled, and highly responsive systems. Sound intriguing? Let's dive in and see how EDA can empower your development journey. How Does Software Based on Event-Driven Architecture Work? Imagine a user placing an order on your e-commerce website. In EDA terms, this is an event, a significant change that triggers a chain reaction. The order creation event gets published, and interested parties subscribe and react accordingly. The inventory system updates stock, the payment processor charges the customer, and the shipping module prepares for delivery. Each service reacts independently, based on the event it's interested in, creating a loosely coupled ecosystem. What Are the Benefits of Using Event-Driven Architecture for Software Developers? This event-centric approach comes with a bunch of perks for developers: Scalability on Demand Need to handle peak traffic? No problem! EDA scales horizontally by adding more event consumers. This system gets rid of monolithic bottlenecks. Built-In Resilience Events are like mini transactions, allowing for fault tolerance and easy recovery. A failed service won't derail the entire system. Improved Flexibility EDA adapts easily. Thanks to the loose coupling, developers can add new services without affecting existing ones. Real-Time Reactivity Want instant responses? EDA enables event-driven microservices that react to changes in real-time, perfect for building responsive systems. Where Do You See EDA in Action? The possibilities are endless when it comes to what can be defined as an event. Some of the common examples of events that people normally create every day include: When a new user signs up on a website to create an account Subscribing to a YouTube channel is also an event. E-commerce order processing Real-time analytics in IoT Systems Chat applications constantly update messages What Are the Components of EDA? Broadly speaking, there are four components to Event-Driven Architecture, which are listed below with a brief description: Event: The user action causes a state change. Service or event handler: The event causes the services or event handler to react appropriately. It can include a process or further event generation. Event loop: The event loop is responsible for facilitating a smooth flow of interactions between the events and services. Event flow layers: There are three event flow layers, namely, event producer, event consumer, and event channel/router. What Are Some of the Challenges and Considerations When Using Event-Driven Architecture? No silver bullet exists, and EDA comes with its own set of challenges. Debugging distributed systems can be trickier, and designing complex event flows requires careful planning. But fear not; with the right tools and knowledge, these challenges are manageable. Start Your EDA Journey Ready to explore the world of events? Dive into resources like the Apache Kafka documentation or try out frameworks like Spring Cloud Stream. Start with small projects to get comfortable, and soon, you'll be building powerful, reactive systems like a pro! Remember: EDA is a paradigm shift, not a replacement. Consider your project's specific needs and carefully evaluate the trade-offs before diving in. The Future Is Event-Driven EDA is more than just a trend; it is a powerful approach shaping the future of software development. With its flexibility, scalability, and real-time capabilities, EDA empowers developers to build robust and responsive systems that can adapt to the ever-changing demands of the digital world. So, what are you waiting for? Embrace the event-driven revolution and unleash the power of reactive systems! The emerging trends like serverless computing and event sourcing will further enhance the power of EDA. Therefore, developers who want to stay up-to-date and offer better services must consider adding this to their arsenal of skill sets.

By Dennis Helfer

Mastering System Design: A Comprehensive Guide to System Scaling for Millions (Part 1)

Take a transformative journey into the realm of system design with our tutorial, tailored for software engineers aspiring to architect solutions that seamlessly scale to serve millions of users. In this exploration, we use the fictitious MarsExpress, a local delivery startup in Albuquerque, as a model to illustrate the evolution from a community service to a global force. MarsExpress, our focal point, currently operates on an aging monolithic system — a legacy structure that once served its purpose locally but now yearns for a comprehensive overhaul. Join us as we unravel the intricacies of system design, not merely for theoretical understanding but as a hands-on approach to rejuvenating a legacy system into a globally scalable software solution. This tutorial transcends conventional coding tutorials, shifting the focus towards the strategic decisions and methodologies that propel a software solution from a local operation to a worldwide phenomenon. Forget geographical limitations and delve into the world of strategic architectural choices that dictate scalability. MarsExpress, with its legacy monolith, serves as our canvas, unraveling the intricacies of system design without delving into code specifics. Instead, we provide software engineers with the tools to engineer solutions that scale effortlessly and globally. Join us on this odyssey, where MarsExpress becomes a model for the transformation from localized operations to a globally impactful service. This tutorial is an open invitation for software engineers keen on mastering system design — an essential skill set for crafting software solutions that cater to millions. Legacy Monolithic MarsExpress currently operates on a traditional monolithic architecture, often referred to as the “legacy system.” In this setup, the server is openly accessible via the Internet, offering a RESTful API to manage essential business logic. This API serves as the bridge for communication between mobile and web client applications and the server, enabling the exchange of data and commands. One notable aspect of the current system is its responsibility for delivering static content, such as images and application bundles. These elements are stored directly on the local disk of the server, contributing to the overall functionality and user experience. Additionally, the application server is closely linked to the database, which is housed on the same server. This connection facilitates the seamless interaction between the application’s logic and the data it relies on, creating a centralized environment for information storage and retrieval. Scaling Vertically In our quest to transform MarsExpress into a global powerhouse, the first step involves scaling vertically to bolster its capacity and handle a substantial increase in user demand. Scaling vertically, often referred to as “scaling up,” focuses on enhancing the capabilities of the existing server and infrastructure to manage a higher load of users. As the server grapples with an increasing user load, a short-term remedy involves upgrading to a larger server equipped with enhanced CPU, memory, and disk space. However, it’s important to note that this serves as a temporary solution, and over time, even the most robust server will encounter its capacity constraints. Also, the lack of redundancy in a single-server architecture makes the system vulnerable to failures. In the event of hardware issues or routine maintenance, downtime becomes an unavoidable consequence, rendering the entire system temporarily inaccessible. Performance bottlenecks also emerge as a noteworthy issue. With a burgeoning user base and expanding data volume, a single server can become a significant performance bottleneck. This bottleneck manifests as slower response times, adversely affecting the overall user experience. Geographic limitations pose another challenge. A single server, typically located in a specific geographic region, can result in latency for users situated in distant locations. This constraint becomes increasingly pronounced when aspiring to cater to a global user base. The concentration of data on a single server also raises concerns about data loss. In the unfortunate event of a catastrophic failure or unexpected circumstances, the risk of losing significant data becomes a stark reality. Additionally, the maintenance and upgrade processes on a single server can be cumbersome. Implementing updates or performing maintenance tasks often requires system downtime, impacting users’ access to services and making the overall system management less flexible. In light of these drawbacks, it becomes imperative to explore more robust and scalable system design approaches, especially when aiming to create a production environment capable of handling millions of users while ensuring reliability and optimal performance. Scaling Horizontally In a single-server architecture, horizontal scaling emerges as a strategic solution to accommodate increasing demands and ensure the system’s ability to handle a burgeoning user base. Horizontal scaling involves adding more servers to the system and distributing the workload across multiple machines. Unlike vertical scaling, which involves enhancing the capabilities of a single server, horizontal scaling focuses on expanding the server infrastructure horizontally. One of the key advantages of horizontal scaling is its potential to improve system performance and responsiveness. By distributing the workload across multiple servers, the overall processing capacity increases, alleviating performance bottlenecks and enhancing the user experience. Moreover, horizontal scaling offers improved fault tolerance and reliability. The redundancy introduced by multiple servers reduces the risk of a single point of failure. In the event of hardware issues or maintenance requirements, traffic can be seamlessly redirected to other available servers, minimizing downtime and ensuring continuous service availability. Scalability becomes more flexible with horizontal scaling. As user traffic fluctuates, additional servers can be provisioned or scaled down dynamically to match the demand. This elasticity ensures efficient resource utilization and cost-effectiveness, as resources are allocated based on real-time requirements. Load Balancer In the realm of horizontal scaling, a load balancer becomes our strategic ally. It acts as a guardian at the gateway, diligently directing incoming requests to the array of servers in our cluster. Here’s how it seamlessly integrates into our horizontally scaled architecture. A load balancer ensures that incoming requests are evenly distributed across all available servers. This prevents any single server from bearing the brunt of heavy traffic, promoting optimal resource utilization. the effectiveness of a load balancer often depends on the strategy and algorithm it uses to distribute incoming requests among servers. In load-balancing strategies, algorithms are categorized into two primary types: static and dynamic. These classifications represent distinct approaches to distributing incoming network traffic across multiple servers. Each type serves specific purposes and is tailored to meet particular requirements in system design. Static load balancing algorithms, in contrast, follow predetermined patterns for distributing incoming requests among available servers. While they offer simplicity and ease of implementation, like: Round Robin: Round Robin is a static load balancing algorithm that distributes incoming requests in a circular order among available servers. This method is straightforward, ensuring an even distribution of traffic without considering the current load or capacity of each server. It is well-suited for environments with relatively uniform servers and stable workloads. Weighted Round Robin: Weighted Round Robin is a static load balancing approach similar to Round Robin but introduces the concept of assigning weights to each server based on its capacity or performance. This static method allows administrators to predetermine the load distribution, considering variations in server capacities. IP Hash: IP Hash is a static load-balancing algorithm that utilizes a hash function based on the client’s IP address to determine the server for each request. This ensures session persistence, directing requests from the same client to the same server. While effective for maintaining stateful connections, it may lead to uneven distribution if the IP hashing isn’t well-distributed. Randomized: The Randomized load balancing algorithm introduces an element of unpredictability by randomly selecting a server for each request. This static method can be advantageous in scenarios where a uniform distribution of requests is not critical, adding an element of randomness to the load distribution. Dynamic load balancing algorithms adapt in real time to the changing conditions of a system. These algorithms continuously assess server health, current loads, and response times, adjusting the distribution of incoming requests accordingly. Like: Least Connections: Dynamic in nature, the Least Connections algorithm routes incoming traffic to the server with the fewest active connections. This dynamic approach adapts to real-time connection loads on servers, efficiently distributing requests and optimizing resource usage based on the current server states. Least Response Time: The Least Response Time algorithm dynamically directs traffic to the server with the fastest response time. It optimizes server performance and responsiveness, ensuring that users are consistently directed to the server with the lowest latency. Least Resource Utilization: Dynamic in its behavior, the Least Resource Utilization algorithm routes traffic to the server with the lowest resource utilization, considering factors such as CPU and memory usage. This dynamic approach responds to changes in server resource usage, optimizing for efficiency. Adaptive Load Balancing: Adaptive Load Balancing dynamically adjusts the distribution algorithm based on real-time server health and load conditions. This dynamic approach continuously adapts to changing circumstances, offering optimal performance by responding to fluctuations in server states. The dynamic load balancing algorithm I would recommend for “MarsExpress,” as it scales globally, is the Least Connections algorithm. This algorithm is particularly advantageous because it considers the current state of the network when making routing decisions and assigning new requests to the server with the fewest active connections. One of the primary benefits of the Least Connections method is its ability to adapt to traffic variations. As the system expands, it is likely to experience unpredictable spikes in usage. The algorithm can manage these fluctuations by distributing incoming requests to servers with lighter loads, thus preventing any single server from being overwhelmed. This algorithm also supports session persistence, which is critical for a delivery system that requires transaction consistency. Modified to consider session affinity, the Least Connections method ensures that requests from a specific user during a session are consistently directed to the same server, maintaining a continuous user experience. Data Replication Data replication is a fundamental aspect of large-scale distributed systems, playing a critical role in enhancing their efficiency, reliability, and availability. In such systems, data replication involves creating multiple copies of data and distributing them across different servers or locations. This strategy is vital for ensuring high availability; if one node fails or becomes inaccessible, users can still access data from another node, minimizing downtime and service disruptions. Additionally, replication aids in load balancing by allowing requests to be distributed across multiple nodes, thereby reducing the load on any single server and improving overall system performance. It also enhances data access speed, as users can access data from the nearest or least busy replica, significantly reducing latency. While data replication is prominently recognized for its role in distributed databases, it is important to note that its utility extends beyond traditional data storage systems. Replication can be equally vital in caching layers, such as those implemented using cache servers like Redis. Selecting the appropriate replication strategy for a system can be a complex decision, as various strategies offer distinct advantages and challenges. The suitability of a replication strategy largely depends on the specific needs and contexts of the use case at hand. Some strategies may excel in certain scenarios, while others might be more effective under different circumstances. three main replication strategies are: Leader-Follower (also known as Master-Slave) Replication: In the Leader-Follower replication strategy, one node (the leader or master) handles all write operations, and several other nodes (followers or slaves) replicate these changes. The leader node receives all update requests, processes them, and then propagates the changes to its followers. This method ensures consistency and simplifies conflict resolution, as there is a single authoritative source for data updates. Multi-Leader Replication: Multi-Leader replication allows multiple nodes to act as leaders, each capable of handling write operations. These leaders then synchronize their data with each other. This approach is beneficial in distributed systems where nodes are geographically dispersed, as it allows writes to occur closer to where the data is being used, reducing latency. Leaderless Replication: In the Leaderless replication model, all nodes are treated equally and can handle both read and write operations. When a write occurs, it is usually written to multiple nodes to ensure redundancy. Reads may require responses from multiple nodes to ensure the data is up-to-date, based on a quorum-like system. This model offers high availability and fault tolerance, as there is no single point of failure, and operations can continue even if some nodes are down. Also, conflict resolution is a critical aspect of database replication to ensure data consistency and integrity. Various conflict resolution strategies can be employed, including: Last Write Wins (LWW): This strategy resolves conflicts by accepting the last write operation as the correct version, potentially discarding earlier conflicting changes. Timestamp-Based Resolution: Conflicts are resolved based on timestamps associated with write operations, with the latest timestamp taking precedence. Manual Resolution: In some cases, conflicts require manual intervention by administrators or users to determine the correct version of the data. Conflict Avoidance: Designing data models and application logic to minimize the likelihood of conflicts through techniques like logical clocks and unique identifiers. Consistency Matters Consistency in distributed systems is crucial as it ensures that all users and processes have a uniform view of data at any given time. This is vital for maintaining data integrity and preventing conflicts or errors that can arise from disparate data states. In scenarios like financial transactions, inventory management, or any system where data accuracy is paramount, consistency ensures reliable and predictable interactions. Without consistency, systems can produce incorrect results, leading to potential data loss, erroneous decisions, or system failures. In summary, consistency is key to the reliable and accurate operation of distributed systems. Eventual consistency is a model used in distributed systems, where it’s accepted that all copies of data across nodes may not be immediately consistent following a change but will become consistent after a period. This approach allows for high system availability and performance, especially in environments with network latency and partitioning issues. Eventual consistency is well-suited for applications where immediate data consistency is not critical, and slight delays in data synchronization can be tolerated. This model is often used in large-scale, distributed databases and applications like social networks, where scalability and availability are prioritized over strict consistency. The linearizability consistency model in distributed systems ensures that operations appear to occur instantaneously and sequentially, even if they are executed concurrently. This model provides a high level of data integrity and consistency, making it ideal for systems where precise coordination of operations is critical. Linearizability is akin to having a single, global clock dictating the order of all operations, thus simplifying the understanding and predictability of system behavior. It’s most beneficial in scenarios requiring strict consistency, like financial transactions or critical data updates, where the exact ordering of operations is vital. The sequential consistency model in distributed systems is a consistency level where the result of execution of operations (like read and write) is as if the operations were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program. It ensures system-wide ordering of operations, making it simpler to understand than more relaxed consistency models. This model is useful for applications where the order of operations needs to reflect the program order, but it does not require operations to be instantaneous like Linearizability. For example, consider an online marketplace with a shared inventory system. When multiple sellers update their inventory concurrently, the sequential consistency model ensures that these updates are reflected across the system in the order they were made. The causal consistency model in distributed systems ensures that operations that are causally related maintain a specific order across all nodes, while operations that are unrelated can be seen in any order. This model is crucial in scenarios like social media platforms, where user actions such as posting a message and commenting on that message are causally linked. The causal consistency ensures that if a user sees comments only after the original message is visible. In such a system, if one user comments on another user’s post, the comment will not appear to others until the original post is also visible, maintaining a logical and understandable sequence of events. This consistency model is ideal for applications where the context and sequence of interactions are important for user experience and data integrity. Stronger consistency models impose order constraints that limit the utility of asynchronous replication, while weaker models offer more flexibility at the risk of stale data. This understanding is crucial for selecting the right replication approach. The trade-off with asynchronous replication’s flexibility is the potential lag between leader and follower nodes, which can introduce several consistency challenges that need careful consideration. Consistency in distributed systems can be fraught with challenges. One of them is read-your-own-write inconsistency. It is a phenomenon encountered in distributed systems where data written or updated by a user is not instantly visible to that same user upon subsequent reads. In other words, when a user makes a change to their data, such as updating their profile information or posting a message, they expect to immediately see the updated data when they access it again. However, in distributed systems, there can be delays in propagating these changes across all nodes or replicas, leading to a situation where the user’s own updates are not immediately reflected in their own subsequent read requests. This inconsistency can result from factors like replication lag, network delays, or the inherent complexities of maintaining real-time data synchronization across distributed nodes. It’s a challenge in systems where maintaining immediate consistency can be difficult due to the need to balance performance, availability, and data accuracy. To address this issue, distributed systems often employ various synchronization mechanisms and strategies to minimize the delay and provide users with a more coherent and real-time experience. it becomes evident that discussing inconsistency and consistency requires dedicated articles that explore their nuances, challenges, and solutions. Conclusion In this initial segment of our series, we’ve embarked on MarsExpress’s journey, transforming its legacy monolithic architecture into a scalable structure ready for global challenges. We’ve explored the fundamentals of vertical and horizontal scaling, along with load balancing and data replication, setting the stage for more complex scalability solutions. As we look ahead, the next part of our series will delve into the realms of caching and sharding, which are crucial for enhancing performance and managing data efficiently on a global scale. These advanced techniques will be pivotal in propelling MarsExpress to new heights, ensuring it can handle the demands of millions seamlessly. Join us as we continue to unravel the intricacies of system design, which is essential for any software engineer aiming to build robust, scalable systems in today’s dynamic technological landscape.

By Alireza Rahmani Khalili

CORE

IntelliJ and Java Spring Microservices: Productivity Tips With GitHub Copilot

Have you ever wished for a coding assistant who could help you write code faster, reduce errors, and improve your overall productivity? In this article, I'll share my journey and experiences with GitHub Copilot, a coding companion, and how it has boosted productivity. The article is specifically focused on IntelliJ IDE which we use for building Java Spring-based microservices. Six months ago, I embarked on a journey to explore GitHub Copilot, an AI-powered coding assistant, while working on Java Spring Microservices projects in IntelliJ IDEA. At first, my experience was not so good. I found the suggestions it provided to be inappropriate, and it seemed to hinder rather than help development work. But I decided to persist with the tool, and today, reaping some of the benefits, there is a lot of scope for improvement. Common Patterns Let's dive into some scenarios where GitHub Copilot has played a vital role. Exception Handling Consider the following method: Java private boolean isLoanEligibleForPurchaseBasedOnAllocation(LoanInfo loanInfo, PartnerBank partnerBank){ boolean result = false; try { if (loanInfo != null && loanInfo.getFico() != null) { Integer fico = loanInfo.getFico(); // Removed Further code for brevity } else { logger.error("ConfirmFundingServiceImpl::isLoanEligibleForPurchaseBasedOnAllocation - Loan info is null or FICO is null"); } } catch (Exception ex) { logger.error("ConfirmFundingServiceImpl::isLoanEligibleForPurchaseBasedOnAllocation - An error occurred while checking loan eligibility for purchase based on allocation, detail error:", ex); } return result; } Initially, without GitHub Copilot, we would have to manually add the exception handling code. However, with Copilot, as soon as we added the try block and started adding catch blocks, it automatically suggested the logger message and generated the entire catch block. None of the content in the catch block was typed manually. Additionally, other logger.error in the else part is prefilled automatically by Co-Pilot as soon as we started typing in logger.error. Mocks for Unit Tests In unit testing, we often need to create mock objects. Consider the scenario where we need to create a list of PartnerBankFundingAllocation objects: Java List<PartnerBankFundingAllocation> partnerBankFundingAllocations = new ArrayList<>(); when(this.fundAllocationRepository.getPartnerBankFundingAllocation(partnerBankObra.getBankId(), "Fico")).thenReturn(partnerBankFundingAllocations); If we create a single object and push it to the list: Java PartnerBankFundingAllocation partnerBankFundingAllocation = new PartnerBankFundingAllocation(); partnerBankFundingAllocation.setBankId(9); partnerBankFundingAllocation.setScoreName("Fico"); partnerBankFundingAllocation.setScoreMin(680); partnerBankFundingAllocation.setScoreMax(1000); partnerBankFundingAllocations.add(partnerBankFundingAllocation); GitHub Copilot automatically suggests code for the remaining objects. We just need to keep hitting enter and adjust values if the suggestions are inappropriate. Java PartnerBankFundingAllocation partnerBankFundingAllocation2 = new PartnerBankFundingAllocation(); partnerBankFundingAllocation2.setBankId(9); partnerBankFundingAllocation2.setScoreName("Fico"); partnerBankFundingAllocation2.setScoreMin(660); partnerBankFundingAllocation2.setScoreMax(679); partnerBankFundingAllocations.add(partnerBankFundingAllocation2); Logging/Debug Statements GitHub Copilot also excels in helping with logging and debugging statements. Consider the following code snippet: Java if (percentage < allocationPercentage){ result = true; logger.info("ConfirmFundingServiceImpl::isLoanEligibleForPurchaseBasedOnAllocation - Loan is eligible for purchase"); } else{ logger.info("ConfirmFundingServiceImpl::isLoanEligibleForPurchaseBasedOnAllocation - Loan is not eligible for purchase"); } In this example, all the logger information statements are auto-generated by GitHub Copilot. It takes into account the context of the code condition and suggests relevant log messages. Code Commenting It helps in adding comments at the top of the method. In the code snippet below, the comment above the method is generated by the Copilot. We just need to start typing in // This method. Java // THis method is used to get the loan program based on the product sub type public static String getLoanProgram(List<Product> products, Integer selectedProductId) { String loanProgram = ""; if (products != null && products.size() > 0) { Product product = products.stream().filter(p -> p.getProductId().equals(selectedProductId)).findFirst().orElse(null); if (product != null) { String productSubType = product.getProductSubType(); switch (productSubType) { case "STANDARD": loanProgram = "Standard"; break; case "PROMO": loanProgram = "Promo"; break; default: loanProgram = "NA"; break; } } } return loanProgram; } Alternatively, we can use a prompt like // Q : What is this method doing?. Copilot will add the second line, // A : This method is used to log the payload for the given api name. Java // Q : What is this method doing? // A : This method is used to log the payload for the given api name public static void logPayload(String apiName, Object payload) { try { if (payload != null && apiName != null && apiName.trim().length() > 0) { ObjectMapper mapper = new ObjectMapper(); String payloadResponse = mapper.writeValueAsString(payload); logger.info("UnderwritingUtility::logPayload - For api : " + apiName + ", payload : " + payloadResponse); } else { logger.error("UnderwritingUtility::logPayload - Either object was null of api name was null or empty"); } } catch (Exception ex) { logger.error("UnderwritingUtility::logPayload - An error occurred while logging the payload, detail error : ", ex); } } Another example of a different method we type in a prompt: // Q : What is this method doing?. Copilot will add the second line, // A : This method is used to validate the locale from request, if locale is not valid then set the default locale. Java //Q - Whats below method doing? //A - This method is used to validate the locale from request, if locale is not valid then set the default locale public static boolean isLocaleValid(LoanQuoteRequest loanQuoteRequest){ boolean result = false; try{ if (org.springframework.util.StringUtils.hasText(loanQuoteRequest.getLocale())){ String localeStr = loanQuoteRequest.getLocale(); logger.info("UnderwritingUtility::validateLocale - Locale from request : " + localeStr); Locale locale = new Locale.Builder().setLanguageTag(localeStr).build(); // Get the language part String language = locale.getLanguage(); if (language.equalsIgnoreCase("en")){ result = true; if (!localeStr.equalsIgnoreCase(UwConstants.DEFAULT_LOCALE_CODE)){ loanQuoteRequest.setLocale(UwConstants.DEFAULT_LOCALE_CODE); } } else if (language.equalsIgnoreCase("es")){ result = true; if (!localeStr.equalsIgnoreCase(UwConstants.SPANISH_LOCALE_CODE)){ loanQuoteRequest.setLocale(UwConstants.SPANISH_LOCALE_CODE); } } } else{ result = true; loanQuoteRequest.setLocale(UwConstants.DEFAULT_LOCALE_CODE); } } catch (Exception ex){ logger.error("UnderwritingUtility::validateLocale - An error occurred, detail error : ", ex); } return result; } Closing Thoughts The benefits of using GitHub Copilot in IntelliJ for Java Spring Microservices development are significant. It saves time, reduces errors, and allows us to focus on core business logic instead of writing repetitive code. As we embark on our coding journey with GitHub Copilot, here are a few tips: Be patient and give it some time to learn and identify common coding patterns that we follow. Keep an eye on the suggestions and adjust them as needed. Sometimes, it hallucinates. Experiment with different scenarios to harness the full power of Copilot. Stay updated with Copilot's improvements and updates to make the most of this cutting-edge tool. We can use this in combination with ChatGPT. Here is an article on how it can help boost our development productivity. Happy coding with GitHub Copilot!

By Amol Gote

CORE

Microservices vs. Monolith at a Startup: Making the Choice

The reality of the startup is that engineering teams are often at a crossroads when it comes to choosing the foundational architecture for their software applications. This decision, seemingly technical at its core, extends far beyond the area of coding, straight into the strategic planning that can make or break the early stages of a startup. At the heart of this decision lies a crucial question: should these teams lay the groundwork with a microservice architecture, known for its distributed and decentralized nature, or opt for a monolithic design, where the entire application is unified and interdependent? The allure of a microservice architecture is understandable in today's tech state of affairs, where scalability, flexibility, and independence are highly valued. The appeal of building a system that's inherently designed to grow and adapt as the startup evolves is undeniable. Microservices promise a distributed architecture where each service runs its unique process and communicates through a well-defined, lightweight mechanism. This approach offers many advantages, particularly in enabling teams to update and deploy individual components without disrupting the entire system. However, this very allure might lead to a premature commitment to a microservice architecture, especially in scenarios where time is of the essence, and the startup needs to establish itself as a reliable and viable business quickly. The complexity of designing, deploying, and maintaining a network of microservices can be a significant undertaking, often underestimated by many. This complexity can introduce unexpected delays, increase the risk of downtime, and demand a level of operational maturity that a fledgling startup may still need to possess. In contrast, a monolithic architecture, often viewed as traditional or outdated, can offer surprising advantages, particularly for startups in their nascent stages. A monolithic application, where all components are interconnected and interdependent, provides a straightforward, unified model for development. This approach can significantly simplify the development process, reduce the time to market, and allow for rapid prototyping and iteration — crucial factors for startups that need to demonstrate their business model's feasibility swiftly. Given these contrasting paths, startup engineering teams must weigh their options carefully, considering not just the technical aspects, but also how their choice aligns with their business goals, team capabilities, and the urgency of market entry. There is no doubt that there are a lot of reviews and analyses of both approaches out there giving the precise answer, but in this article, we will be looking at real-life examples so you can make your own decisions, but this time much more informed. At the end of the day, both architecture types have their own advantages, and it is up to one’s startup’s peculiarities to define what to choose. Or maybe there is no need to choose at all…? The Appeal of Monolithic Architecture Monolithic architecture, characterized by a single, unified codebase for an application, presents a compelling option for startups due to its simplicity and efficiency. This architecture style, where all components are interconnected and interdependent, simplifies both the development and deployment processes. Case Study 1: Stack Overflow Stack Overflow's choice of a monolithic architecture certainly illustrates the power of this approach. Despite handling over 6000 requests per second and 2 billion page views per month, Stack Overflow operates on a single application running on IIS, servicing 200 sites with remarkable efficiency. This setup, comprised of a singular SQL Server supported by extensive caching and a streamlined tech stack, is managed by a team of just 50 engineers. Their ability to deploy updates rapidly several times daily showcases the operational agility that a well-structured monolithic system can offer. Case Study 2: Shopify Shopify, another giant in the tech industry, utilizes a modular monolith approach, wherein all code is housed within one codebase, yet it's modularized for better management. This method allows for clear delineation of business domains such as orders, shipping, and billing, each with its dedicated interface and data ownership. Maintaining a single repository and deployment pipeline allows Shopify to reap the benefits of streamlined maintenance and enhanced collaboration across all its teams. Bonus: My Personal Experience at a Bike and Scooter Sharing Startup Drawing from personal experience in a bike and scooter sharing startup, the decision to adopt a monolithic architecture led to a remarkably quick launch, within just four months. This monolithic approach facilitated the development of a simple prototype to a full-blown application, complete with credit card payments, IoT integration, and essential operational tooling. Its simplicity allowed us to rapidly set up the infrastructure and maintain a clear understanding of the entire codebase. This streamlined architecture enabled us to deploy more than 5,000 bikes to the streets simultaneously at launch. Furthermore, it proved highly effective in scaling the service to meet the rapid growth in user rates we experienced, accommodating more than 1 million users in the first six months of operation. The monolithic design's inherent agility and simplicity were key in managing these significant scales and changes efficiently and swiftly. You might now think now: Shopify, Stack Overflow — the giants, even the author’s personal successful experience… Is there any sense in proceeding with microservices, if monolithic architecture is that good? Sure. Don’t worry, I have other examples to enrich your purview. Keep up. The Shift to Microservices The shift toward microservices architecture represents a strategic move for many startups, particularly as they scale and evolve. Microservices, characterized by their distributed nature where each service runs independently, offer significant advantages in terms of scalability, flexibility, and the ability to adapt to changing needs. Case Study 3: Nubank A prime example of this approach is Nubank, a company that embraced microservices from its inception in 2013. This decision defied conventional wisdom, which typically advises starting with a monolithic architecture for speed and ease of initial development. Nubank's choice to start with microservices was based on a strategic assessment of its business model and market. Although this approach initially slowed down their development process, it allowed them to invest in a solid infrastructure foundation, which paid dividends as they began to scale and expand their features. The journey wasn't without challenges. Nubank had to continuously adapt and refine its service boundaries as it gained a deeper understanding of its domain. This ongoing process of evaluation and adjustment truly speaks louder than anything about the dynamic nature of microservices, which allow for continuous improvement and optimization. Bonus 2.0: Health Tech Startup Based on my experience in a health tech startup, a decision was made in an even more interesting way: to adopt a quasi-microservice architecture, balancing the need for a secure, scalable system with the practicalities of a small team. This approach, distinct from traditional microservices, involves dividing the application into manageable layers and sections, each overseen by a dedicated team to foster accountability and focus. We implemented this architecture atop a monolithic data access layer, centralizing high-standard privacy and security requirements vital in health tech. This setup allowed teams to work independently without individually handling these critical compliance aspects. Additionally, we used a single monorepository for all services, coupled with a unified deployment pipeline. Furthermore, to counter typical microservices challenges, we developed a standardized, user-friendly inter-service communication mechanism. This system effectively mitigates issues like low development productivity and data inconsistency. Thus, the quasi-microservice architecture's flexibility was key in rapidly adapting to changing requirements and scaling specific system components as needed. Conclusion: Making the Decision Based on the Key Factors When startups face the pivotal decision of choosing between microservices and monolithic architectures, several key factors kick in. Firstly, the size of the engineering team is crucial. A smaller team might find it easier to manage and develop within a monolithic architecture, whereas larger teams can leverage the distributed nature of microservices to work on different components simultaneously. Project complexity also plays a significant role: simple projects with a clear and stable scope may benefit more from a monolithic approach, while complex evolving projects might be better suited to microservices. Scalability needs are another critical factor. If rapid scaling is what you want, microservices offer the flexibility and scalability necessary to accommodate growth. However, if scalability is not an immediate concern, the simplicity of a monolith could be more advantageous. The impact of current tooling and technology trends cannot be overlooked as well. The availability of tools and frameworks supporting microservices or monolithic architectures can significantly influence the ease of development and maintenance. The main thought behind all these examples and reasoning is that startups are encouraged to assess their unique circumstances carefully, making a choice that aligns with their business goals, team dynamics, and the competitive landscape they operate in. Maybe a quasi-microservice architecture is the way to go for you? Or you might prefer to experiment with other approaches? Once again, the decision between microservices and monolithic architectures is more than a technical choice, and the assessment of all factors is the real key to your perfect match.

By Gustavo Ribeiro Amigo

Exploring the Horizon of Microservices With KubeMQ's New Control Center

The software development landscape is rapidly evolving. New tools, technologies, and trends are always bubbling to the top of our workflows and conversations. One of those paradigm shifts that has become more pronounced in recent years is the adoption of microservices architecture by countless organizations. Managing microservices communication has been a sticky challenge for many developers. As a microservices developer, I want to focus my efforts on the core business problems and functionality that my microservices need to achieve. I’d prefer to offload the inter-service communication concerns—just like I do with authentication or API security. So, that brings me to the KubeMQ Control Center (KCC). It’s a service for managing microservices communication that’s quick to set up and designed with an easy-to-use UI. In this article, I wanted to unpack some of the functionality I explored as I tested it in a real-world scenario. Setting the Scene Microservices communication presents a complex challenge, akin to orchestrating a symphony with numerous distinct instruments. It demands precision and a deep understanding of the underlying architecture. Fortunately, KCC—with its no-code setup and Kubernetes-native integration—aims to abstract away this complexity. Let's explore how it simplifies microservices messaging. Initial Setup and Deployment Deploy KubeMQ Using Docker The journey with KCC starts with a Docker-based deployment. This process is straightforward: Shell $ docker run -d \ -p 8080:8080 \ -p 50000:50000 \ -p 9090:9090 \ -e KUBEMQ_TOKEN=(add token here) kubemq/kubemq This command sets up KubeMQ, aligning the necessary ports and establishing secure access. Send a "Hello World" Message After deployment, you can access the KubeMQ dashboard in your browser at http://localhost:8080/. Here, you have a clean, intuitive UI to help you manage your microservices. We can send a “Hello World” message to test the waters. In the Dashboard, click Send Message and select Queues. We set a channel name (q1) and enter "hello world!" in the body. Then, we click Send. Just like that, we successfully created our first message! And it’s only been one minute since we deployed KubeMQ and started using KCC. Pulling a Message Retrieving messages is a critical aspect of any messaging platform. From the Dashboard, select your channel to open the Queues page. Under the Pull tab, click Pull to retrieve the message that you just sent. The process is pretty smooth and efficient. We can review the message details for insights into its delivery and content. Send “Hello World” With Code Moving beyond the UI, we can send a “Hello world” message programmatically too. For example, here’s how you would send a message using C#. KCC integrates with most of the popular programming languages, which is essential for diverse development environments. Here are the supported languages and links to code samples and SDKs: C# and .NET Java Go Node.js Python Deploying KubeMQ in Kubernetes Transitioning to Kubernetes with KCC is pretty seamless, too. KubeMQ is shooting to design with scalability and the developer in mind. Here’s a quick guide to getting started. Download KCC Download KCC from KubeMQ’s account area. They offer a 30-day free trial so you can do a comprehensive evaluation. Unpack the Zip File Shell $ unzip kcc_mac_apple.zip -d /kubemq/kcc Launch the Application Shell $ ./kcc The above step integrates you into the KubeMQ ecosystem, which is optimized for Kubernetes. Add a KubeMQ Cluster Adding a KubeMQ cluster is crucial for scaling and managing your microservices architecture effectively. Monitor Cluster Status The dashboard provides an overview of your KubeMQ components, essential for real-time system monitoring. Explore Bridges, Targets, and Sources KCC has advanced features like Bridges, Targets, and Sources, which serve as different types of connectors between KubeMQ clusters, external messaging systems, and external cloud services. These tools will come in handy when you have complex data flows and system integrations, as many microservices architectures do. Conclusion That wraps up our journey through KubeMQ's Control Center. Dealing with the complexities of microservice communication can be a burden, taking the developer away from core business development. Developers can offload that burden to KCC. With its intuitive UI and suite of features, KCC helps developers be more efficient as they build their applications on microservice architectures. Of course, we’ve only scratched the surface here. Unlocking the true potential of any tool requires deeper exploration and continued use. For that, you can check out KubeMQ’s docs site. Or you can build on what we’ve shown above, continuing to play around on your own. With the right tools in your toolbox, you’ll quickly be up and running with a fleet of smoothly communicating microservices! Have a really great day!

By John Vester

CORE

Architecture Style: Modulith (vs. Microservices)

Modulith architecture is a style of software design that emphasizes modularity within a monolithic application. It aims to combine the simplicity and straightforward deployment model of a monolithic architecture with the modularity and maintainability typically associated with microservices. In a modulith, the application is structured as a collection of loosely coupled modules, each encapsulating a specific business capability or domain. These modules interact with each other through well-defined interfaces, yet they are deployed as a single unit, similar to a traditional monolithic application. In a modulith, the application is structured as a collection of loosely coupled modules, each encapsulating a specific business capability or domain. So, a monolithic application would look like this: Monolithic application So a modulithic application would look like this: Modulith application Benefits Enhanced Modularity Moduliths promote a clean separation of concerns by organizing code into distinct modules. This separation enhances the maintainability and understandability of the codebase, making it easier for teams to manage large and complex applications. Simplified Deployment Unlike microservices, which require complex orchestration for deployment, moduliths are deployed as a single unit. This simplifies the deployment process and reduces the operational overhead associated with managing multiple services. No Network Overhead Moduliths operate without the additional network overhead typical in microservices. This is due to their internal module communication being in-process, eliminating the latency and complexity associated with network calls between separate services. Fit Well With a DDD Approach Modulith architecture aligns well with Domain-Driven Design (DDD). It naturally supports bounded contexts by allowing each domain model to be encapsulated within its own module, fostering a clear domain model and business logic separation. Trade-Offs Potential for Tight Coupling While moduliths aim for loose coupling between modules, there’s a risk of inadvertently introducing tight coupling, which can lead to challenges in module isolation and independent scaling. Even with modular separation, coupling is not guaranteed as it is with microservices. Complexity in Scaling Moduliths may not scale as efficiently as microservices in certain scenarios. Scaling a modulith often means scaling the entire application rather than individual components, which can be less efficient. Technology Stack Limitations In a modulith, the entire application typically shares a common technology stack. This can limit the flexibility to use different technologies or programming languages best suited for specific modules, as often done in a microservices architecture. Spof Todo Modulith or Microservices When deciding between modulith and microservices architectures, the key factor is the level of coupling you’re comfortable with. More coupling simplifies maintenance but comes with trade-offs, like scalability complexity. For instance, if part of your application faces heavy loads distinct from the rest, a microservices approach could allow for targeted scaling. Choosing different frameworks or languages also justifies using microservices. However, for isolating domains within an app, like products and clients, a modulith can be effective. It keeps these domains together for versioning and lifecycle management, simplifying CI/CD and database maintenance while still maintaining a manageable level of coupling through modularization. Ultimately, the best choice depends on your specific needs, and often, a combination of both approaches works well. Often, a combination of both approaches works well. Spring Modulith Implementation Overview Spring Modulith is an approach for implementing the modulith architecture using the Spring framework. It is designed to help developers structure their Spring applications in a modular way, following the principles of modulith architecture. Example from Baeldung Key Features Module Definition: Spring Modulith allows defining modules within a Spring application. Each module encapsulates its own business logic, data access, and Spring components. Inter-module Communication: It provides mechanisms for modules to communicate with each other through events or shared interfaces, maintaining loose coupling. It also could be done using event between modules. Note: If you make an interaction between modules that is not correct, the compilation will not fail; you need to implement a test that will fail to prevent that kind of usage. This is based on the ArchUnit tests. Module Isolation: While each module is part of the same monolithic application, Spring Modulith enforces boundaries to prevent unintended dependencies and tight coupling. Testing and Development: Spring Modulith supports testing at the module level, enabling developers to write and run tests for individual modules without the need for the entire application context. More information here. Conclusion In conclusion, the Modulith architecture offers a balanced approach to application design, blending monolithic simplicity with microservices’ modularity. It suits scenarios where domain isolation within a single application is required. While moduliths enhance modularity, reduce deployment complexity, and align well with Domain-Driven Design, they face challenges in scaling and technology flexibility. The decision between moduliths and microservices hinges on the acceptable level of coupling, with a hybrid approach often being effective. Spring Modulith specifically caters to the Spring framework, facilitating module definition, inter-module communication, and isolation while supporting effective testing strategies.

By Pier-Jean MALANDRINO

CORE

Microservices Architecture: Navigating the Buzz

Lately I’ve been exploring what all the talk around "microservices architecture" is really about. From it popping up in every other social media debate to it increasingly becoming a must-have skill on job listings, what is it that has caused this strong divide between the proponents of the traditional monolithic approach and those who have embraced the microservices paradigm? In this article, I’m here to break it down for you as I outline the benefits, some common challenges, and offer some insights from microservices experts for those considering this approach. Monolith vs. Microservices in a Nutshell If you are not already familiar with monolithic vs. microservices architecture, you could imagine your software application as a structure made of Lego bricks. With monolithic architecture, you have one large Lego brick encompassing your entire application and all of its functionality. On the other hand, microservices architecture would be comparable to having a collection of smaller, specialized Lego bricks, each serving as individual components with specific tasks. Image 1: Monolith vs. microservices architecture More technically, microservices architecture is an approach to building software that involves breaking applications down into small, independent services. Each service focuses on a specific and explicit task and interacts with other services through well-defined interfaces. In fact, many of the key concepts of microservices have a lot in common with the Unix philosophy, which Mike Gancarz sums up as: Small is beautiful Make each program do one thing well Build a prototype as soon as possible Share or communicate data easily Use software leverage to your advantage Make every program a filter* In a nutshell, microservices architecture encapsulates the Unix philosophy of “Do one thing and do it well,” with some key characteristics being: Services are small, decentralized, and independently deployable Services are independent of each other and interact through well-defined interfaces, allowing them to be developed in different languages Services are organized around business capabilities Image 2: Visual representation of microservices Benefits of Microservices Architecture 1. Scalability As there are clear boundaries between microservices in terms of their code base and functionality, when it comes to adapting your system to meet evolving demands, scaling up or down can be done by adding or removing microservices (Lego bricks) without affecting the rest of an application. This contrasts with monolith applications where modifying or removing functionality can be cumbersome. Moreover, the scalability of microservices architecture lends itself to cloud deployment, for example as it allows for cloud resources to scale at the same rate as the application. 2. Maintainability and Resilience When it comes to development and maintainability, new features, bug fixes, and improvements, teams can focus on doing this for individual microservices without it affecting the rest of an application. As microservices are independent of each other, there is also greater application resilience, as a failure with one microservice does not lead to a complete system shutdown. 3. Developer Scalability and Team Productivity At an organizational level, it can often be difficult to scale the number of developers working on a project at the same rate that a project itself may be scaling; microservices structured by functionality can help to tackle this challenge. For instance, even with just a single developer, having microservices that are separated by functionality is beneficial in terms of having each segment logically arranged from a technical point of view, for reasons we just explored. With larger development teams, there is often a lack of awareness between different IT segments about each other’s projects, which can lead to complexity and confusion, as well as overlap or tasks going unassigned. Again, by having a microservices architecture that is segmented based on functionality, and which provides clearer boundaries, this allows the structure of your microservices to largely reflect your organizational chart. Teams can work on their tasks largely independently and at their own pace, and by reducing the need for extensive coordination, this translates to increased productivity and improved output quality. Challenges of Microservices Architecture Despite the apparent advantages, there are various challenges that I think are important to highlight. Worth noting is that they are all avoidable when considered and planned around upfront. A common reason why teams end up sticking with a traditional monolithic approach includes the fact that microservices bring increased complexity. This complexity comes in the form of teams needing to understand how to design, build, and manage distributed systems. More specifically, not knowing how to implement a reliable communication protocol for microservices to be able to communicate is a recurring pain point that leads to decreased system performance, and in turn, has teams switching back to their monolithic system. Another challenge that arises from having an increased number of interactions comes in the form of system testing and debugging. Aside from these difficulties, another major concern when considering microservices includes that of security. Implementing robust authentication, authorization, and encryption across each and every service is crucial. As much as these are valid concerns and are very real everyday challenges, working with microservices does not have to be so confusing, and these are all avoidable when considered upfront. Microservices Tips and Tricks If you are considering making the monolith-to-microservices switch, one top recommendation from microservices experts is to make sure that your microservices are independently deployable. More specifically, it is key that a microservice remains simple in terms of its functionality. It should “Do one thing and do it well” and should not depend on other services for its task. Below we can see how this approach affects the release process. For example, in the case of failure, with microservices, only one microservice needs to be retested and redeployed. Image 3: Comparing the release process for monolithic vs. microservices architecture While there are a few design approaches to building microservices, one that is recommended is that of Event-Driven Architecture (EDA). This design pattern supports the loosely coupled, asynchronized communication and decentralized control that is necessary in microservices architecture. Briefly, this is due to the fact that microservices can communicate indirectly through events rather than, for example, through direct API calls. For more details on developing with Event-Driven Architecture, see here. Moreover, if your application has stringent latency requirements and you have performance concerns when it comes to having to communicate between microservices, this article delves into some things to consider when building low-latency systems with a microservices architecture. Conclusion While microservices may be trendy, the benefits of scalability, resilience, and productiveness are anything but temporary. Despite challenges, software frameworks and mindful architecture design can mitigate complexity. Ultimately, the decision to switch to a microservices approach depends on specific business needs, but if flexibility and resilience are priorities, embracing the distributed future of software development is worth considering. *A filter is a program that gets most of its data from its standard input (the main input stream) and writes its main results to its standard output (the main output stream).

By Jasmine Taylor

Event-Driven Process Orchestration: A Practitioner’s Viewpoint

Customers today seek agile, nimble, flexible, and composable services. Services that are unhindered and unencumbered. Services that are easy to access and even easier to experience. Services that are quick and precise. These factors affect the collective CSAT and NPS of a modern-day enterprise. Enterprises acknowledge this, and hence, around 85% of medium to large-sized enterprises are already using the microservices architecture. The distributed architecture of microservices applications renders the components of the applications independent, decentralized, failure resistant, maintained, and upgraded in isolation, therefore fueling self-sufficiency, scalability, system reliability, and simplified service offerings. However, while microservices architecture readies the application for agile servicing, true customer experience arises not solely from the decoupled application components but the way in which every step in a customer success workflow triggers a logical subsequent step automatically to ensure customer delight. This is because as the business process extends and more components get added, “cohesion chaos” can become a reality. The absence of proper orchestration of process steps in a logical flow, keeping the customer end goal in mind, can quickly render the supposed benefits of the microservices landscape futile. Therefore, the microservices applications can be clustered, and the sequence of steps in each process flow can be orchestrated via an event streaming platform like Kafka while being managed and governed by a BPM or Integration engine, say a RHPAM or a Camunda or even MuleSoft that promises seamless co-existence of API led architecture and events-based architecture. Such an architecture will encapsulate various microservices in an event stream, with each service listening intently to the action taken by a user through the topic published into the event stream and the basis of that action, triggering a corresponding service as per the logical process flow defined. Therefore, each service is self-responsible and acts or reacts basis their trigger point in the true spirit of event-based orchestration. In my conversations with enterprises cutting across various geographies and domains, customers usually test the waters of this model of servicing through an event streaming platform like Kafka or centrally orchestrate the service through a BPMN engine like RHPAM. However, both these options have their own pros and cons. The hybrid model, which considers both a BPMN engine for centralized process orchestration while coordinating with the worker services via an event stream, is gaining very good traction and the rise of Enterprise Integration behemoths such as MuleSoft, which claim to support event-driven architecture alongside the more familiar API led integration is making the solution options very interesting for customers. Let’s evaluate these scenarios one by one by taking the use case of Bob, who wants to book a Ridola from Amsterdam to Den Haag, and see which services need to interact with each other to make the experience pleasant for Bob and how some of these tools make the experience seamless. The Mechanism at Play in Bob’s Ordering of a Ridola In ordering a Ridola, assuming he is signing in for the very first time, Bob would open the application and will undergo a journey through the following microservices- Customer Profile Service - Location Service, Cab and Driver Management, Trip Management, and Payments. The value chain, in layman's terms, flows with Bob opening the app, registering himself by providing his profile details, and then choosing the locations to and from which he needs to journey, upon which Ridola searches and recommends the available cabs and drivers in his vicinity with the associated tariff. Upon Bob’s decision of the cab, the trip management service manages the trip by guiding the driver and getting Bob his chosen cab, initiating the trip from Amsterdam towards Den Haag, post the completion of which, Bob is requested for the payment and upon payment a bill is sent to his email address. Options Available for Ridola To Provide a Well-Orchestrated Service to Bob BPMN-Driven Centralized Orchestration In this approach, Ridola would ingrain the business workflow logic in the centralized BPM Engine (say RHPAM, Camunda, etc.) These BPM technologies follow the Business Process Modeling Notation (BPMN), which is a standard for modeling business processes. The integration between Passenger UI and the application would be through REST. The moment Bob logs into the application, the centralized engine (the brain of the business workflow) triggers a command to the worker services and awaits their response. Such commands are issued by the Java delegate or something like AWS Lambda. The overall “cab ordering service” is built as a Springboot microservice. This means the first command from the centralized engine, upon Bob’s log-in, will be issued to the Customer Profile Service, which shall pop up and request Bob to sign in. Upon the completion of that step, the centralized engine shall command the location service to kick in that enquires Bob on his current location and his origin and destination stations. Thereafter, the cab and driver management service gets triggered centrally, and so on and so forth. BPMN-based orchestration architecture The moot point to note in this approach is the central orchestration engine triggering the actions on the worker services. The worker services do not pass the command to each other. This is all centrally managed using BPMN standards, thus enabling easy maintenance, support, and upgrades. The BPM engine can also become the single repository providing transaction updates, service state, etc., and, therefore, a source to drive observability. However, on the flip side, such one-on-one integration between the centralized orchestration engine and each of the worker services can render the landscape “tightly coupled” with “point-to-point integration,” precisely what an enterprise wants to avoid by embracing a microservices architecture. Therefore, while this approach is fair when the number of transactions is low, for a large enterprise like Ridola with a massive number of transactions, such an approach can very quickly heat the orchestration engine and spoil the experience that Ridola wants to provide the end customer. Event-Driven Orchestration Vis-à-vis the centralized approach explored in the above section, many customers seem to be choosing an event streaming platform-led orchestration. This could entail the usage of technologies such as Apache Kafka, IBM Data Streams, Amazon Kinesis, Confluent, etc. This is a decentralized approach where the business logic is imbued across all the microservices that Bob shall encounter while getting his cab service from Ridola. Each of these services – be it customer profile service, location service, cab & driver management service, trip management, or payment service, is integrated with a central event stream (say a Kafka or a Confluent) and listens to the required topic that pertains to the service. This topic that is published to the event stream is a result of the action taken by Bob (by signing into the app) or a result of the action taken by the preceding service (say, customer profile service). This topic is also a trigger or cue for the next service (say location) to get triggered by asking Bob about his location and his from and to stations. Likewise, each service becomes aware of its turn and responsibility through the topic published on the event stream, and the cab ordering process gets streamlined service after service in a true event-driven manner. Event Streaming-based orchestration While this approach brings in the “loose coupling” that the first approach lacked, the maintenance and upkeep of services will become tedious when the overall business process undergoes a change, thereby affecting the sub-services within that value chain. Likewise, there is no centralized observability of performance available, and each service needs to be referred to for logs and traces. This means in case of any error or troubleshooting, we would need to check each service one by one, which would take time. However, if a process value chain is fairly established and the services comprising the process are quite established, such an approach can work. The business owner needs to evaluate the scenarios and take a call. Hybrid Approach: BPMN-Led Event Orchestration Many customers understand the potent combination of the earlier two approaches and choose to undertake proof of value and, thereafter, full-blown implementation of such a hybrid solution. In this, while the centralized BPM engine (RHPAM or Camunda) houses the business logic, the communication with worker services downstream doesn’t take place in a point-to-point manner. This communication is established via the event broker. Therefore, loose coupling is ensured between the services. BPMN-led Event Orchestration As seen above, the moment Bob logs into the application, the centralized engine triggers a command to the worker services via the event streams and awaits their response. Such commands are issued by the Java delegate or something like AWS Lambda. Through this approach, the enterprise stands to gain centralized governance and observability benefits while not making the ecosystem tightly coupled and difficult to maintain. This is a very good model for large enterprises and is seeing wide adoption. MuleSoft + Event-Driven Orchestration Enterprise Integration is a given in any large enterprise, and most enterprises today, including Ridola, leverage API-led integration. However, even in an API-led architectural setup (which is synchronous in nature), there are scenarios where asynchronous communication becomes very important from a business standpoint. This is where event-driven architecture becomes an able foil for the API-led architecture, and they both can complement and co-exist beautifully to ensure that a customer like Bob is not hampered owing to internal architectural limitations. Some such scenarios where such a marriage of synchronous (API-led) and asynchronous (event-led) are seen as plausible are: Asynchronous Backend Updates: MuleSoft follows a three-layered architecture with Experience APIs servicing the customers across multiple channels on the top, Process APIs, which are the pipelines that process the actual task at hand and pass on the outcome to the Experience APIs, and the System APIs at the bottom which are the repository of enterprise data which is tapped on to by the Process APIs to make the solution contextual and tailored. Sometimes, there may come an avalanche of customer requests and the Process APIs may get overwhelmed by the repeated need to fetch data from the System APIs. Such to and fro can add to the latency in servicing the needs of the Experience APIs. Event Stream layer between System and Process APIs helps faster processing It is in such a scenario (as shown above) that an event broker can act as a storehouse of the most requested information (say customer information) and will act as a “one-stop shop” source for this information for the Process APIs and can asynchronously update appropriate systems with the needed information, thus preventing any unnecessary, repeated to and fro call to the CRM system for every Process API request. MuleSoft possesses connectors to various systems, which can help in capturing the data change and publishing it as simple events to the event broker. The upstream applications can then act as event consumers to subscribe to these events and update the end systems. Delayed processing owing to system overload and acknowledgment of customer requests: Sometimes, when the system layer fails after reaching its peak capacity, the to and fro between Experience APIs, Process APIs, and System APIs would continue repeatedly in a futile manner, further overloading the system. It could also happen that the system is down for maintenance over the weekend, but the requests are being received during that window. In such a scenario, MuleSoft-driven applications can generate simple events for every request at the Experience or Process layers, and those events can be stored in an event broker until the end system is ready to process the request. The requesting system will acknowledge the customer request, and those requests that can be addressed using the available Process or System APIs will still get processed in a timely manner. for those others for which sufficient information is not available, a notification stating possible delay can be sent to avoid any customer dissonance. These are emerging as key themes with modern-day customers who want to use the best of API-led and Event-led architectures to ensure seamless customer service, coupled with the avoidable burden on the systems. Conclusion Enterprises are wading through the “experience economy” and the only way to win market share is by winning the confidence of customers. This is where BPMN-led Event Orchestration strategically struck a balance between API-led and event-led architectures that can ensure system resilience, process pragmatism, and delightful customer experience, all in a continuum. This is the right time for enterprises to explore use cases contextual to their respective domain and then evaluate how can a combination of the above approaches help them in their business pursuit. All these approaches have their pros and cons and depend on several factors, such as the process value chain maturity of an enterprise, the frequency, and intensity of changes, the scale of these changes, the number of transactions, the breadth of the customer base, so on and so forth. Making the right decision and choosing the right option for the right use case can be a challenging process that may require careful due diligence and therefore, several enterprises worldwide are partnering with the leading System Integrators in the ecosystem. Thus, if you are thinking about embarking on Event orchestration, you have many ready partners to guide and walk you through the journey. Get started now !!

By Ved Prakash

How To Implement Java Microservices Architecture

Implementing a microservices architecture in Java is a strategic decision that can have significant benefits for your application, such as improved scalability, flexibility, and maintainability. Here's a guide to help you embark on this journey. Understand the Basics Before diving into the implementation, it's crucial to understand what microservices are. Microservices architecture is a method of developing software systems that focuses on building single-function modules with well-defined interfaces and operations. These modules, or microservices, are independently deployable and scalable. Design Your Microservices Identify Business Capabilities Break down your application based on business functionalities. Each microservice should represent a single business capability. Define Service Boundaries Ensure that each microservice is loosely coupled and highly cohesive. Avoid too many dependencies between services. Choose the Right Tools and Technologies Java Frameworks Spring Boot: Popular for building stand-alone, production-grade Spring-based applications. Dropwizard: Useful for rapid development of RESTful web services. Micronaut: Great for building modular, easily testable microservices. Containerization Docker: Essential for creating, deploying, and running microservices in isolated environments. Kubernetes: A powerful system for automating deployment, scaling, and management of containerized applications. Database Use a database per service pattern. Each microservice should have its private database to ensure loose coupling. Develop Your Microservices Implement RESTful Services Use Spring Boot to create RESTful services due to its simplicity and power. Ensure API versioning to manage changes without breaking clients. Asynchronous Communication Implement asynchronous communication, especially for long-running or resource-intensive tasks. Use message queues like RabbitMQ or Kafka for reliable, scalable, and asynchronous communication between microservices. Build and Deployment Automate build and deployment processes using CI/CD tools like Jenkins or GitLab CI. Implement blue-green deployment or canary releases to reduce downtime and risk. Service Discovery and Configuration Service Discovery Use tools like Netflix Eureka for managing and discovering microservices in a distributed system. Configuration Management Centralize configuration management using tools like Spring Cloud Config. Store configuration in a version-controlled repository for auditability and rollback purposes. Monitoring and Logging Implement centralized logging using ELK Stack (Elasticsearch, Logstash, Kibana) for easier debugging and monitoring. Use Prometheus and Grafana for monitoring metrics and setting up alerts. Security Implement API gateways like Zuul or Spring Cloud Gateway for security, monitoring, and resilience. Use OAuth2 and JWT for secure, stateless authentication and authorization. Testing Write unit and integration tests for each microservice. Implement contract testing to ensure APIs meet the contract expected by clients. Documentation Document your APIs using tools like Swagger or OpenAPI. This helps in maintaining clarity about service endpoints and their purposes. Conclusion Implementing a Java microservices architecture can significantly enhance your application's scalability, flexibility, and maintainability. However, the complexity and technical expertise required can be considerable. Hiring Java developers or availing Java development services can be pivotal in navigating this transition successfully. They bring the necessary expertise in Java frameworks and microservices best practices to ensure your project's success. Ready to transform your application architecture? Reach out to professional Java development services from top Java companies today and take the first step towards a robust, scalable microservice architecture.

By Shalaka Gadgil

Unveiling the Power of Helidon 4: A Dive Into New Features

In the ever-evolving landscape of microservices development, Helidon has emerged as a beacon of innovation. The release of Helidon 4 brings forth a wave of enhancements and features that promise to redefine the way developers approach microservices architecture. In this article, we embark on a detailed journey, unraveling the intricacies of Helidon 4's new features through insightful examples. From MicroProfile 6.0 compatibility to enhanced support for reactive programming, simplified configuration management, and seamless integration with Oracle Cloud Infrastructure (OCI), Helidon 4 positions itself at the forefront of modern microservices frameworks. The Shift From Netty: Why Simplicity Matters Netty, known for its efficiency and scalability, played a crucial role in powering Helidon's HTTP server in earlier versions. However, as Helidon evolved, the framework's maintainers recognized the need for a simpler and more approachable architecture. This led to the decision to move away from Netty, making room for a more straightforward and user-friendly experience in Helidon 4. In previous versions, setting up a Helidon web server with Netty involved configuring various Netty-specific parameters. With Helidon 4, the process is more straightforward. Java public class SimpleWebServer { public static void main(String[] args) { WebServer.create(Routing.builder() .get("/", (req, res) -> res.send("Hello, Helidon 4!")) .build()) .start() .await(); } } In this example, the simplicity is evident as the developer creates a web server with just a few lines of code, without the need for intricate Netty configurations. Routing, a fundamental aspect of microservices development, becomes more intuitive. Java public class SimpleRouting { public static void main(String[] args) { WebServer.create((req, res) -> { if (req.path().equals("/hello")) { res.send("Hello, Helidon 4!"); } else { res.send("Welcome to Helidon 4!"); } }).start().await(); } } This example showcases the streamlined routing capabilities of Helidon 4, emphasizing a more natural and less verbose approach. MicroProfile 6.0: A Synergistic Approach Helidon 4's support for MicroProfile 6.0 signifies a crucial alignment with the latest standards in the microservices landscape. Developers can now leverage the enhancements introduced in MicroProfile 6.0 seamlessly within their Helidon applications, ensuring compatibility and interoperability with other MicroProfile-compliant services. MicroProfile Config simplifies the configuration of microservices, allowing developers to externalize configuration parameters easily. In Helidon 4, MicroProfile Config is seamlessly integrated, enabling developers to harness its power effortlessly. Java public static void main(String[] args) { String appName = ConfigProvider.getConfig().getValue("app.name", String.class); System.out.println("Application Name: " + appName); } In this example, the MicroProfile Config API is used to retrieve the value of the "app. name" configuration property, showcasing how Helidon 4 integrates with MicroProfile Config for streamlined configuration management. MicroProfile Fault Tolerance introduces resilience patterns to microservices, enhancing their fault tolerance. Helidon 4 seamlessly incorporates these patterns into its microservices development model. Java public class FaultToleranceExample { @CircuitBreaker(requestVolumeThreshold = 4) public void performOperation() { // Perform microservice operation } } In this example, the @CircuitBreaker An annotation from MicroProfile Fault Tolerance defines a circuit breaker for a specific microservice operation, showcasing Helidon 4's support for fault tolerance. Enhanced Support for Reactive Programming Helidon 4 places a strong emphasis on reactive programming, offering developers the tools to build responsive and scalable microservices. Java // Reactive programming with Helidon 4 WebServer.create(Routing.builder() .get("/reactive", (req, res) -> res.send("Hello, Reactive World!")) .build()) .start() .await(10, SECONDS); In this example, the reactive endpoint is defined using Helidon's routing. This allows developers to handle asynchronous operations more efficiently, crucial for building responsive microservices. Improved Configuration Management Helidon 4 introduces enhancements in configuration management, simplifying the process of externalized configuration. Java # application.yaml for Helidon 4 server: port: 8080 Helidon 4 allows developers to configure their microservices using YAML files, environment variables, or external configuration services. The application.yaml file above demonstrates a straightforward configuration for the server port. Integrated Health Checks and Metrics Helidon 4's integration of health checks and metrics offers a comprehensive solution, providing developers with real-time insights into application health, proactive issue identification, and data-driven decision-making for optimal performance. Defining Custom Health Checks to assess specific aspects of their microservices. In the following example, a custom health check is created to verify the responsiveness of an external service Java HealthSupport.builder() .addLiveness(() -> { // Custom health check logic boolean externalServiceReachable = checkExternalService(); return HealthCheckResponse.named("external-service-check") .state(externalServiceReachable) .build(); }) .build(); Here, the addLiveness method is used to incorporate a custom health check that evaluates the reachability of an external service. Developers can define various checks tailored to their application's requirements. Enabling Metrics for Key Components, such as the web server Java MetricsSupport.builder() .config(webServerConfig) .build(); In this snippet, metrics support is configured for the web server, providing granular insights into its performance metrics. Developers can extend this approach to other components critical to their microservices architecture. Exposing Metrics Endpoints, facilitating easy consumption by external monitoring tools. Java PrometheusSupport.create() .register(webServer); Here, Prometheus support is created, allowing developers to register the web server for metrics exposure. This integration streamlines the process of collecting and visualizing metrics data. Simplified Security Configuration Security is paramount in microservices, and Helidon 4 streamlines the configuration of security features. Java // Security configuration in Helidon 4 Security security = Security.builder() .addProvider(JwtProvider.create()) // Add JWT authentication provider .addProvider(HttpBasicAuthProvider.create()) // Add HTTP Basic authentication provider .build(); In this example, Helidon's Security module is configured to use JWT authentication and HTTP Basic authentication. This simplifies the implementation of security measures in microservices. Expanded MicroProfile Rest Client Support Microservices often communicate with each other, and Helidon 4 expands its support for MicroProfile Rest Client. Java // MicroProfile Rest Client in Helidon 4 @RegisterRestClient public interface GreetService { @GET @Path("/greet") @Produces(MediaType.TEXT_PLAIN) String greet(); } Here, a MicroProfile Rest Client interface is defined to interact with an /greet endpoint. Helidon 4 simplifies the creation of type-safe REST clients. Oracle Cloud Infrastructure (OCI) Integration The integration of Helidon 4 with Oracle Cloud Infrastructure represents a pivotal shift in microservices development. OCI, renowned for its scalability, security, and performance, becomes the natural habitat for Helidon 4, empowering developers to harness the full potential of cloud-native development. Configuring OCI Properties in Helidon 4 Java import io.helidon.config.Config; import io.helidon.config.ConfigSources; public class OCIConfigExample { public static void main(String[] args) { Config config = Config.builder() .sources(ConfigSources.classpath("application.yaml")) .addSource(ConfigSources.create(OCIConfigSource.class.getName())) .build(); String ociPropertyValue = config.get("oci.property", String.class).orElse("default-value"); System.out.println("OCI Property Value: " + ociPropertyValue); } } In this example, the OCIConfigSource integrates OCI-specific configuration into the Helidon configuration, allowing developers to access OCI properties seamlessly. They are leveraging OCI Identity and Access Management (IAM). OCI IAM plays a crucial role in managing access and permissions. Helidon 4 allows developers to leverage IAM for secure microservices deployment effortlessly. Java public class HelidonOCIIntegration { public static void main(String[] args) { Security security = Security.builder() .addProvider(OidcProvider.builder() .identityServerUrl("https://identity.oraclecloud.com/") .clientId("your-client-id") .clientSecret("your-client-secret") .build()) .build(); WebSecurity.create(security, webServer -> { // Configure security for web server }); } } In this example, the Helidon application integrates with OCI's Identity and Access Management through the OIDC provider, allowing developers to enforce secure authentication and authorization in their microservices. Deploying Helidon Microservices on OCI Java public static void main(String[] args) { Server.builder() .port(8080) .start(); } Streamlined Project Templates Getting started with microservices development is made easier with Helidon 4's streamlined project templates. Java # Create a new Helidon project with Maven archetype mvn archetype:generate -DinteractiveMode=false \ -DarchetypeGroupId=io.helidon.archetypes \ -DarchetypeArtifactId=helidon-quickstart-mp \ -DarchetypeVersion=2.0.0 \ -DgroupId=com.example \ -DartifactId=myproject \ -Dpackage=com.example.myproject The Maven archetype simplifies the creation of a new Helidon project, providing a well-defined structure to kickstart development. Conclusion Helidon 4's new features, as demonstrated through real-world examples, showcase the framework's commitment to providing a powerful and developer-friendly environment for microservices development. From MicroProfile compatibility to enhanced support for reactive programming, improved configuration management, and streamlined security configurations, Helidon 4 empowers developers to build scalable and resilient microservices with ease. As the landscape of microservices continues to evolve, Helidon 4 stands out as a versatile and robust framework, ready to meet the challenges of modern application development.

By Andrei Tuchin

CORE

Microservices

DZone's Featured Microservices Resources

Top Microservices Experts

The Latest Microservices Topics