Microservices

In this brief tutorial, let's look at how we can quickly kickstart the codebase of a microservice that can be developed and run in containers. We achieve this by using the Jolie programming language, npm, VS Code, and Docker. Prerequisites You will need npm, Docker, and VS Code installed. Make sure that you have enabled support for Dev Containers in VS Code. (Jolie comes preloaded in the Docker images that we are going to use, so no need to install it.) Ready? Go! 1. Create Your Project With npm Create a new directory for following this tutorial (for example, tutorial) and enter it. Shell mkdir tutorial cd tutorial Now run the following command within that directory from a terminal. Shell npm init jolie You will be asked the usual questions that come with npm init, like the license that you want to use. You will then be presented with Jolie-specific questions. Go ahead and just press enter: the defaults are exactly what we need for this tutorial. In particular, say yes to getting a Dockerfile and a devcontainer configuration. We are going to need those. Next, you choose what kind of Jolie project you want. Select "Empty Jolie project." You should now have the following directory structure (plus the usual node_modules directory). 2. Write Your Service in VSCode Open the tutorial's directory with VSCode. Shell code . The editor will automatically detect the presence of the .devcontainer folder and ask us if we want to reopen the directory in a container. Go ahead and do that by clicking the blue button below. Creating the container might take a while the first time. When VS Code is done with preparations, you should see the green confirmation shown below in the status bar at the bottom of the window. Now we can start coding! In this tutorial, we create a simple service that accepts HTTP requests for generating greetings, which carry the name to greet in the query string. For example, invoking http://localhost:8080/greet?name=Jane should return a JSON value like { greeting: "Hi Jane" }. Open the main.ol file, which contains an empty service called Main. We start by writing the API of our service. It contains a single operation called greet, which receives messages of type GreetRequest and replies with messages of type GreetResponse. For more details, you can check this introduction to Jolie or the Jolie documentation. type GreetRequest { name: string } type GreetResponse { greeting: string } interface GreeterInterface { RequestResponse: greet( GreetRequest )( GreetResponse ) } service Main { main { // Your code here } } We can now implement our API in the service Main, obtaining the following code. type GreetRequest { name: string } type GreetResponse { greeting: string } interface GreeterInterface { RequestResponse: greet( GreetRequest )( GreetResponse ) } service Main { execution: concurrent inputPort GreeterInput { location: "socket://localhost:8080" protocol: http { format = "json" } interfaces: GreeterInterface } main { greet( request )( { greeting = "Hi " + request.name } ) } } The property execution: concurrent tells Jolie that this service should handle clients concurrently. We then have an inputPort to define an access point for our API, which is available at localhost at TCP port 8080 (location), uses HTTP as transport with JSON as the preferred format (protocol), and exposes the interface we defined previously (interfaces). In the main block, we define the implementation of the greet operation simply by sending back "Hi" followed by the name in the request. 3. Run It! We can run our service within the Dev Container by using the terminal in VS Code. Go to Terminal -> New Terminal to open a terminal, as shown below. You should now see a terminal panel like the following. Run the following command in it. Shell jolie main.ol Your service should be running (without any visible output), and port 8080 should be automatically forwarded to your local machine. You can test the service by running a command like the following from a normal terminal in your local machine (outside of VS Code). Here we use curl, but any tool for performing HTTP requests should work (including your browser). Shell curl 'http://localhost:8080/greet?name=Jane' When you want to build a Docker image out of your project, you can use the automatically-generated Dockerfile. The following command will create a Docker image. Shell docker build . -t tutorial:latest To test it, you can run it locally like this: Shell docker run -p 8080:8080 -it --rm tutorial:latest For an explanation of the flags, check the Docker run documentation. Essentially, -p 8080:8080 makes port 8080 available to the host, -it runs the container interactively, and --rm removes the container once it terminates. You should be able to test the service by running the same curl command shown above. You can also watch this tutorial in the video below. That's it! We have created a codebase for developing a microservice with Jolie in a Dev Container and deploying it with Docker!

Python is one of the options when choosing between programming languages suitable for microservices architecture. It has perks like an active community, better prototyping, and popularity among developers. It has some limitations, so other languages can be used to avoid them. Quick Development Architectural Style Review and Statistics Two main development architectural styles are monolithic architecture and microservices architecture. Monolithic has an all-in-one principle and functions as an integral structure, which works best for small development projects or start-ups. When a platform grows and a business needs complex applications, it'll be reasonable to split it into a microservices architecture. Some languages and frameworks are better suited for building microservices architecture. Java, Javascript, and Python were listed as the most popular languages for microservices development. According to this DZone post, Java is preferred by the majority (82%), then comes Node.js (40%), and Python and client-side JavaScript (31%). According to JetBrains, the 3 most popular programming languages for microservices architecture are Java (41%), Javascript (37%), and Python (25%). Some are better for monolithic architecture. In fact, many businesses choose to build monolithic applications as the monolithic approach was more widespread until some decades ago. As we see, microservices in Python is not the first choice but is quite often picked by developers, so let's discuss it in detail. Microservices in Python A dynamic language without a static type system would be suited for microservices architecture. The combination of the programming language and this architecture provides an opportunity to create unique solutions and complex applications in software. Technically, every language that can establish communication between microservices will work. Creating microservices in Python allows using certain features/libraries/tools that might not be available elsewhere. Moreover, in case you need to iterate fast and the team can do your best with Python, it will be the right choice. Seek functionality in Python as it's an object-oriented language, so it is beneficial to add specific functions. Main Types of Microservices Architecture in Python To understand the nature of microservices in Python, let's look at two different types of them: all-to-all service and event-driven type. All-to-all service looks similar to the usual development process. The relationship between microservices in Python is partly vertical, so they constitute a chain and are activated one by one. The communication between microservices here is more strict. The all-to-all service is similar to a monolithic approach but divided into separate blocks. Communication is faster and more complicated in the event-driven type of microservices architecture. The principle here is that the microservice gets triggered after certain conditions. In other words, when the user and application interact (a request), the software executes certain actions (events). Communication Between Microservices Microservices-based applications are not as straightforward as monolithic applications, so communication between them is more chaotic. Here the processes don't activate each other but rather react to events or requests. Separate services need specific software called message brokers to create connections. They have different functionality and specifics. Amazon Web Services offer ready solutions, but development teams can choose message brokers themselves. The most popular are RabbitMQ, ZeroMQ, Apache ActiveMQ, Apache Kafka, IBM MQ, etc. Advantages of Python in Microservices Architecture With the right API formatting, prototyping is easier and quicker than in other languages. Prototyping serves good for correcting design problems and identifying improvements. Python allows developers to automate systems provisioning and configurations for microservices. Individual code changes get replicated throughout the code base. It's compatible with legacy languages like ASP and PHP that help create web service front-ends to host Microservices. The active community of Python developers provides great support and resources when you look for certain info. It doesn't mean other languages don't have that, but Python is generally quite popular. Disadvantages of Python in Microservices Architecture Speed of execution might suffer. Python is an interpreted language, so it generates non-machine code at execution. After that, interpreters like CPython, Jython, PyPy, or PyCharm transform it at runtime into bytecode instructions executed in the CPU's virtual environment. Some languages compile into native code, which is faster to execute (C and C++). Dynamic typing might lead to many errors and crashes. Some errors that were ignored during compilation could appear during runtime. That's risky and might lead to delays or crashes. Developers need to be attentive and test application processes continuously. It might seem obvious, but that adds extra work. My Insights on Microservices in Python We've had a fair share of Python-based apps on microservices architecture. The two most popular frameworks for projects were Flask and Django. The reasons we've worked with them were: Django has various tools to be used in projects. It is faster too, but some choices are made for you, so if you don't agree or want unique application requirements, use other frameworks like Flask or Fast API. Python is good for teams of any size and experience level. Why? Because the language is popular among developers, even though it scales well in expressiveness and freedom, it might be structured and controlled too. There are better alternatives than Python, like Javascript, for microservices architecture, but some clients simply prefer it. A big community, many ready solutions, and fast development make it familiar and trustable. Conclusion If you have the app idea and want to develop using microservices architecture, investigate the most popular frameworks and languages and choose one depending on the functionality you need, the team's expertise, and the resources you have. Business logic and business capabilities are essential here, so think about microservices applications when you have complex systems, want continuous delivery, and need some functionality like asynchronous communication. In other cases, microservices implementation using Python might be pricey and not reasonable.

As microservices systems expand beyond a handful of services, we often need some way to coordinate everything and ensure consistent communication (avoid human error). Tools such as Kubernetes or Docker Compose have quickly become commonplace for these types of workloads. Today’s example will use Docker Compose. Docker Compose is an orchestration tool that manages containerized applications, and while I have heard many lament the complexity of Kubernetes, I found Docker Compose to have some complexities as well. We will work through these along the way and explain how I solved them. For our project, we have two high-level steps to get managed microservice containers - 1. containerize any currently-local applications, 2. set up the management layer with Docker Compose. Let’s get started! Architecture Our microservices system contains quite a few pieces to manage. We have two databases, three API services, a user-view service, and a configuration service. With so many components needing coordination, Docker Compose will reduce manual interaction for starting, stopping, and maintaining individual services by orchestrating them as a united group. The border around each service represents the container housing each application. Notice that only one service is not containerized - Neo4j. The database is managed separately in Neo4j Aura (a Neo4j-hosted cloud service), so we don’t containerize and manage it ourselves. The rest of the services are encompassed in a gray box denoting what Docker Compose handles. Application Setup There are a few steps I would recommend for integrating a microservice with an orchestration tool like Docker Compose. Mostly, they focus on testing and resiliency concerns. Networking, communication, and configuration become a bit more complicated in a microservices environment, so I took a few extra steps and precautions to simplify those components. Create an internal test method. When requests don’t respond, there are many different variables, making it hard to debug. By including a “ping”-like method, we can test only whether the application is live and reachable. Example code is in the GitHub repository for each service. Build in resiliency with retry logic and open health check access. If requests fail or take too long, it is good practice to build in some plan for how you want the service and/or method to react. While doing this didn’t solve all the problems, having the app handle intermittent interruptions on its own takes out some of the guesswork later. By exposing health endpoints, we can also inspect various aspects of the app. More about this is outlined in the application changes section of this blog post. Containerizing Services In order for Docker Compose to manage services, we need to put them into containers. We can use a Dockerfile to set up the commands needed in order to build a container (like a mini virtual machine) that includes the application and any other components we need available. There are a lot of options for what to put in a container, but we will stick with just a few necessary requirements. Dockerfile #Pull base image #----------------- FROM azul/zulu-openjdk:17 #Author #------- LABEL org.opencontainers.image.authors="Jennifer Reif,jennifer@thehecklers.org,@JMHReif" #Copy jar and expose entrypoints #-------------------------------- COPY target/service1-*.jar goodreads-svc1.jar ENTRYPOINT ["java","-jar","/goodreads-svc1.jar"] First, we need a Java environment in the container (since we have Java-based applications), so the FROM command will pull Azul’s version 17 image as the base layer. Next, the LABEL command tells users who owns/maintains the file. Lastly, there are a couple of instructions to copy the JAR file (packaged application) into the container (COPY) and then add commands/arguments for the build command (ENTRYPOINT). We will need a similar file in each service folder (4 services + config service + mongodb service = 6 total). Next, we need to package each application by going into each folder and running the below command to create the bundled application JAR file. Shell mvn clean package Note: For service1, service3, and service4, we need to add -DskipTests=true to the end of the above command. Those services rely on a config server application, and if the tests don’t find one running, the build will fail. The extra option tells Maven to skip that part. Now that we have the application JAR files ready, we need to create a docker-compose.yml file that outlines all the commands and configuration for setup to run the services as a unit! Docker-compose.yml A YAML file will include container details, configuration, and commands that we want Compose to execute. It will list each of our services, then specify subfields for each. We will also set up a dedicated network for all of the containers to run on. Let’s build the file piece by piece in the main project folder using the template below. YAML version: "3.9" services: <service>: <field>: <value> networks: goodreads: The first field displays the Docker compose version (not required). Next, we will list our services. The child fields for each service can hold details and configurations. We will go through those in the next subsections. Lastly, we have a networks field, which specifies a custom network that we want the containers to join. This was the part that took some time to figure out. Docker compose documentation has a page dedicated to networking, but I found the critical information easy to miss. To summarize, if we do not specify a custom network in the Docker compose file, it will create a default network. Each container will only be able to communicate with other containers on that network via IP address. This means if containerA wants to talk to containerB, a call would look like curl http://127.0.0.2:8080. However, if IP addresses expire or rotate, then any references would need to dynamically retrieve the container’s IP address before calling. One way around this is to create a custom network, which allows containers to reference one another by container name, instead of just IP address. This an improvement, both to solve dynamic IP issues, as well as human memory/reference issues. Therefore, the networks field in the docker-compose.yml states any custom network names along with any configurations. Since we don’t need anything fancy, the network name goodreads is the only thing here. We will then assign the services to that same network with an option under each service. Now we need to fill in the services and related options under the services section. MongoDB Database YAML version: "3.9" services: goodreads-db: container_name: goodreads-db image: jmreif/mongodb environment: - MONGO_INITDB_ROOT_USERNAME=mongoadmin - MONGO_INITDB_ROOT_PASSWORD=Testing123 ports: - "27017:27017" volumes: - $HOME/Projects/docker/mongoBooks/data:/data/db - $HOME/Projects/docker/mongoBooks/logs:/logs - $HOME/Projects/docker/mongoBooks/tmp:/tmp networks: - goodreads networks: goodreads: The first service is the MongoDB database container loaded with Book data. To configure it, we have the container name, so we can reference and identify the container by name. The image field specifies whether we want to use an existing image (as we have done here) or build a new image. Note: I am running on Apple silicon architecture. If you are not, you will need to build your own version of the image with the instructions provided on GitHub. This will build the container on your local architecture. The next field sets environment variables for connecting to the database with the provided credentials (username and password). Specifying ports comes next, where we map the host post to the container port, allowing traffic to flow between our local machine and the container via the same port number. Note: It is recommended to enclose the port field values with quotes, as shown. Then, we need to add the container to our custom goodreads network we set up earlier. The final subfield is to mount volumes from the local machine to the container, allowing the database to store the data files in a permanent place so that the loaded data does not disappear when the container shuts down. Instead, each time the container spins up, the data is already there, and each time it spins down, any changes are stored for the next startup. Let’s look at goodreads-config next. Spring Cloud Config Service YAML version: "3.9" services: #goodreads-db... goodreads-config: container_name: goodreads-config image: jmreif/goodreads-config # build: ./config-server ports: - "8888:8888" depends_on: - goodreads-db environment: - SPRING_PROFILES_ACTIVE=native,docker volumes: - $HOME/Projects/config/microservices-java-config:/config - $HOME/Projects/docker/goodreads/config-server/logs:/logs networks: - goodreads Tacking onto our list of services is the configuration server. Just like our database service, we specify the container name and image. We could also substitute the build field (next field that is commented out) for the image field, if we wanted to build the container locally, rather than using a pre-built image. The ports field comes next to map internal and external container ports, followed by the depends_on field, which specifies that the database container must be started before this service can start. Note: This does not mean that the database container is in a "ready" state, only started. Under the environment block, we have a variable set up for a Spring profile. This allows us to use different credentials, depending on whether we are running in a local test environment or in Docker. The main difference is the use of localhost to connect to other services in a local environment (specified by native profile), versus container names in a Docker environment (profile: docker). The next option for volumes sets up the location of the config files (for now, in a local config directory) and log files. We cap off the options by adding the container to our goodreads Docker network. Moving to our numbered services! Spring Boot API Microservice - MongoDB (Books) YAML version: "3.9" services: #goodreads-db... #goodreads-config... goodreads-svc1: container_name: goodreads-svc1 image: jmreif/goodreads-svc1:lvl9 # build: ./service1 ports: - "8081:8081" depends_on: - goodreads-config restart: on-failure environment: - SPRING_APPLICATION_NAME=mongo-client - SPRING_CONFIG_IMPORT=configserver:http://goodreads-config:8888 - SPRING_PROFILES_ACTIVE=docker networks: - goodreads I found this piece to be the toughest one to get working because there were a couple of quirks when interacting with the config service in Docker Compose. This was mostly due to startup order and timing of services with Docker Compose. Let’s walk through it. The first four fields are the same as with previous services (container name, image/build, ports, and depends on), although service1 actually depends on the config service and not the database container directly. This is because the config service supplies the database credentials, so service1 cannot call the database without the config service providing credentials to access the database. Plus, since the config service relies on the database, then service1 can rely on the config service, creating a dependency chain without too much complexity. The next field for restart is new, though. Earlier, I mentioned that depends_on only waits for the container to start, not for the service to be ready. Service1 would start too early and fail to find the configuration. After trying a few different methods, such as building in request retries in the application itself, I discovered that the only working solution was to restart the whole container. The most straightforward way to do this was through the restart option in Docker Compose. This solved the startup and configuration issues I was seeing by automatically restarting the container when the application fails. The following environment variable option specifies the application name, location of the config server, and Spring profile. The application name and active profile help the application find the appropriate configuration file on the config server. The SPRING_CONFIG_IMPORT variable tells the container where to look for the config server. These properties also did not work correctly if I put them in the config file itself. The values had to be accessible within the container, or it would not know where to look. Lastly, we add this container to our custom network. With this core application service added to the mix, services two through four are a bit easier. Spring Boot Client Microservice YAML version: "3.9" services: #goodreads-db... #goodreads-config... #goodreads-svc1... goodreads-svc2: container_name: goodreads-svc2 image: jmreif/goodreads-svc2:lvl9 # build: ./service2 ports: - "8080:8080" depends_on: - goodreads-svc1 restart: on-failure environment: - BACKEND_HOSTNAME=goodreads-svc1 networks: - goodreads The fields should start to seem pretty familiar. We use the container name, image (or build), ports, depends on, and restart options like we did before. The environment option contains a new value for dynamically plugging in a value for the WebClient bean to find the API service (service1). For more background on this feature, check out this blog post. We wrap up with our custom network assignment and charge on to service3! Spring Boot API Microservice - MongoDB (Authors) YAML version: "3.9" services: #goodreads-db... #goodreads-config... #goodreads-svc1... #goodreads-svc2... goodreads-svc3: container_name: goodreads-svc3 image: jmreif/goodreads-svc3:lvl9 # build: ./service3 ports: - "8082:8082" depends_on: - goodreads-config restart: on-failure environment: - SPRING_APPLICATION_NAME=mongo-client - SPRING_CONFIG_IMPORT=configserver:http://goodreads-config:8888 - SPRING_PROFILES_ACTIVE=docker networks: - goodreads This service’s configuration looks nearly identical to that of service1 because they are both providing the same function within the microservices system - an API backing service. The big difference is that service1 is handling Book data objects, and service3 is handling Author data objects. Otherwise, they both use the config service for database credentials to the MongoDB container and also both depend on the config service. Let’s dive into service4! Spring Boot API Microservice - Neo4j (Reviews) YAML version: "3.9" services: #goodreads-db... #goodreads-config... #goodreads-svc1... #goodreads-svc2... #goodreads-svc3... goodreads-svc4: container_name: goodreads-svc4 image: jmreif/goodreads-svc4:lvl9 # build: ./service4 ports: - "8083:8083" depends_on: - goodreads-config restart: on-failure environment: - SPRING_APPLICATION_NAME=neo4j-client - SPRING_CONFIG_IMPORT=configserver:http://goodreads-config:8888 - SPRING_PROFILES_ACTIVE=docker networks: - goodreads This service also mimics services 1 and 3 because it is the API service, but it interacts with a cloud-hosted Neo4j database. The configuration looks nearly identical, except that the environment variable for the application name references the config file containing Neo4j database credentials (versus MongoDB credentials). Time to put everything to the test! Put it to the Test Docker compose will handle starting all of the containers in the proper order, so all we need to do is assemble the command. Shell docker-compose up -d Note: If you are building local images with the build field in docker-compose.yml, then use the command docker-compose up -d --build. This will build the Docker containers each time on startup from the directories. The containers should spin up, and we can verify them with docker ps. Next, we can test all of our endpoints. Goodreads-config (mongo): browser with localhost:8888/mongo-client/docker. Note: Showing default profile to hide sensitive values. Goodreads-svc1: browser with localhost:8081/db/books. Goodreads-svc2: browser with localhost:8080/goodreads/books. Goodreads-svc3: browser with localhost:8082/db/authors. Goodreads-config (neo4j): browser with localhost:8888/neo4j-client/docker. Note: Showing `default` profile to hide sensitive values. Neo4j database: ensure AuraDB instance is running (free instances are automatically paused after 3 days). Goodreads-svc4: browser with localhost:8083/neo/reviews. Bring everything back down again with the below command. Shell docker-compose down Wrapping Up! We have successfully created an orchestrated microservices system with Docker Compose! This post tackled Docker Compose for managing microservices together based on information we specify in the docker-compose.yml file. We also covered some tricky "gotchas" with Docker networks and environment issues related to startup order and dependencies between microservices, but we were able to navigate those with configuration options. There is so much more we can explore with microservices, such as adding more data sources, additional services, asynchronous communication through messaging platforms, cloud deployments, and more. I hope to catch you in future improvements on this project. Happy coding! Resources GitHub: Meta repository for microservices project (this post covers Level 5 and Level 9) Documentation: Docker compose Blog post: Baeldung's Introduction to Docker Compose Documentation: Docker Compose - restart option Neo4j AuraDB: Create a FREE database

Microservices were meant to be a blessing, but for many, they’re a burden. Some developers have even moved away from them after negative experiences. Operational complexity becomes a headache for this distributed, granular software model in production. Is it possible to solve microservices' problems while retaining their advantages? Microservices shorten development cycles. Changing a monolithic code base is a complex affair that risks unexpected ramifications. It’s like unraveling a sweater so that you could change its design. Breaking that monolith down into lots of smaller services managed by two-pizza teams can make software easier to develop, update, and fix. It’s what helped Amazon grow from a small ecommerce outfit to the beast it is today. Microservices also introduce new challenges. Their distributed nature exposes developers to complex state management issues. The Yoda Principle Ideally, developers shouldn’t deal with state management at all. Instead, the platform should handle it as a core abstraction. Database transaction management is a good example; many database platforms support atomic transactions, which divide a single transaction into a set of smaller operations and ensure that either all of them happen, or none of them do. To achieve this behavior the database uses transaction isolation, which restricts the visibility of each operation in a transaction until the entire transaction completes. If an operation fails, the application using the database sees only the pre-transaction state, as though none of the operations happened. This transactionality enables the developer to concentrate on their business logic while the database platform handles the underlying state. A database transaction doesn’t fail half-complete and then leave the developer to sort out what happened. An account won’t be debited without the corresponding party’s account being credited, for example. As Yoda said: “Do or do not. There is no try.” Appreciate ACIDSQL databases, he would have. “Phew,” you think. “Thank goodness I don’t have to write code to unravel half-completed operations just to work out the transaction state.” Unfortunately, microservices developers are still living in that era. This is why Yoda never used Kubernetes. I’ve Got a Bad Feeling About This In microservice architectures, a single business process interacts with multiple services, each of which operates and fails autonomously. There is no single monolithic engine to manage and maintain state in the event of a failure. This lack of transactionality between independent services leaves developers holding the bag. Instead of just focusing on their own applications’ functionality, they must also handle application resilience by managing what happens when things go wrong. What was once abstracted is now their problem. In practice, things can go wrong quickly in microservice architectures, with cascading failures that cause performance and reliability problems. For example, a service that one development team updates can cause other services to fail if they haven’t also been updated to handle those new errors. The brittle complexity of microservices is a challenge, in part because of the weakest link effect. An application’s overall reliability is only as good as its least reliable microservice. The whole thing becomes a lot harder with asynchronous primitives. State management is more difficult if a microservice’s response time is uncertain. Look at the Size of That Thing Another aspect of this problem is that managing state on your own doesn’t scale well. The more microservices a user has, the more time-consuming managing their state becomes. Companies often have thousands of microservices in production, outnumbering their developers. This is what we noticed as early developers at Uber. Uber had 4,000 microservices, even back in 2018. We spent most of our time writing code to manage microservice state in this environment. Developers have taken several approaches to solve for homegrown state management. Some use Kafka event streams hidden behind an API to queue microservice-based messages, but the lack of diagnostics makes root cause analysis a nightmare. Others use databases and timers to keep track of system state. Monitoring and tracing can help, but only up to a point. Monitoring tools oversee platform services and infrastructure health, while tracing makes it easier to troubleshoot bottlenecks and unexpected anomalies. There are many on offer. For example, Prometheus offers open-source monitoring that developers can query, while its sibling Grafana adds visualization capabilities to trace system behavior. These solutions can be useful, providing at least some observability into microservices-based systems. However monitoring tools don’t help with the task of state management, leaving that burden with the developer. That’s why developers spend way too much time writing state management code instead of highly differentiated business logic. In an ideal world, something else would abstract state management for them. Use the Microservices State Management Platform, Luke The answer to simplifying state management in microservices is to offer it as a core abstraction for distributed systems. We worked on a statement management platform after spending far too much time manually managing microservices state at Uber. We wanted a product that would enable us to define workflows that make calls to different microservices (in the language of the developer’s choosing), and then execute them without worrying about it afterwards. In our solution, which we originally called Cadence, a Workflow automatically maintains state while waiting for potentially long-running microservices to respond. Its concurrent nature also enables the workflow to continue with other non-dependent operations in the meantime. The system manages disruption in state without requiring developer intervention. For example, in the event of a hardware failure the state management platform will restart a Workflow on another machine in the same state without the developer needing to do anything. Do. Don’t Not Do. A dedicated state management platform for microservices gives us the same kind of abstraction that we see in atomic database transactions. Developers can be certain that a Workflow will run once, to completion. Temporal takes care of any failures and restarts under the hood. Now, microservices-based applications can guarantee that a debit from one account automatically credits the other in just a couple of lines of code. They get the best of both worlds. This fixes a long-standing problem with microservices and supercharges developer productivity, especially now that they are typically responsible for the operation of their application in addition to the development. Finally, developers that want the benefits of microservices can enjoy them without having to go to the dark side.

Microservices are a popular way to build small, autonomous teams that can work independently. Unfortunately, by their very nature, microservices only work in the backend. Even with the best microservice architecture, frontend development still requires a high degree of interdependence, and this introduces coupling and communication overhead that can slow down everyone. Can we take microservice architecture patterns and apply them to the frontend? It turns out we can. Companies such as Netflix, Zalando, and Capital One have pushed the pattern to the front, laying the groundwork for microfrontends. This article will explore microfrontends, their benefits and disadvantages, and how they differ from traditional microservices. Microservices for the Frontend Microfrontends are what we get when we bring the microservice approach to the frontend. In other words, a microfrontend is made of components — owned by different teams — that can be deployed independently. These components are assembled to create a consistent user experience. A monolith can be decomposed in different ways. We can split frontend and backend or use microservices on the backend. We can even recreate the frontend as a collection of isolated components managed by different teams. With a microfrontend, no single team owns the UI in its entirety. Instead, every team owns a piece of the screen, page, or content. For example, one team might be responsible for the search box, while another might code suggestions based on users’ tastes. Additional teams might code the music player, manage playlists, or render the billing page. We add complexity but teams get increased autonomy in return. Frontend functionalities are managed by different teams, independently deployed, and injected into the homepage transparently to the end user. Benefits and Challenges of Microfrontends Microfrontends offer similar benefits to microservices. Namely, we can scale up development by breaking the frontend code into isolated pieces, for which different teams are responsible. As with microservices, each feature can be released on its own, at any time, with little coordination. This leads to more frequent updates. Vertical Teams Microfrontends enable the creation of vertical teams, which means a full-stack team of developers can own a feature on both the backend and the frontend at the same time. Fullstack vertical teams are responsible for both the frontend and backend of a feature or component. Continuously Deployable Components Every part of a microfrontend is a deployable unit. This allows teams to publish their changes without waiting for a release train or depending on other teams finishing their work. The end result is that the frontend can be updated several times per day. Each team can have separate repositories, CI/CD pipelines, and service machines. Alternatively, we can host everything on a monorepo and have a single shared CI/CD pipeline. Challenges of Microfrontend Design The main challenge of microfrontends is creating a fast and responsive client. We must never lose sight of the fact that the frontend lives in an environment with limited memory, CPU, and network, or we risk ending up with a slow UI. A snappy UI is vital for the success of the product. A recent survey pointed out that “a site that loads in 1 second has a conversion rate 3x higher than a site that loads in 5 seconds”. Every second the user has to wait, money is thrown out of the window. In addition to all the challenges microservices have, microfrontend design poses a few more problems: Isolation: each team’s code must eventually coexist on the same browser. We must be deliberate in isolating the separate modules to avoid collisions of code or style. Shared resources: to avoid duplication and keep the frontend thin, components should share assets and libraries when possible, which may create undesirable coupling. Accessibility: heavy reliance on JavaScript to render the page negatively affects accessibility. Styling: When the UI is made up of components produced by various teams, maintaining a consistent look is more complicated. Small stylistic inconsistencies can feel jarring. Coordination: with so many moving parts, APIs need to be very well-defined and stable. Teams must coordinate on how different components in the microfrontend communicate with each other and the backend microservices. Principles for Building Microfrontends There are two complementary methods for rendering a unified UI from separate microfrontend components: server-side and client-side rendering. Server-Side Rendering (SSR) Server-side rendering offers faster performance and more accessible content. Rendering on the server is a good alternative for serving content quickly — especially on low-power devices like low-end phones. It is also a suitable fallback mode when JavaScript is disabled. The webserver assembles the full page from the content provided by different microservices. This serves as the first contentful page. Hydration can then be used to add more dynamic content. We have a few ways of performing SSR: Server Side Includes (SSI): is a simple scripting language executed by the webserver. The language uses directives to build HTML fragments into a full page. These fragments may come from other files or the responses of programs. SSI is supported by all major webservers, including Apache, Nginx, and IIS. iframes: the venerable iframe feature allows us to embed arbitrary HTML content on a page. Edge Side Includes (ESI): a more modern alternative to SSI. ESI can handle variables, have conditionals, and supports better error handling. ESI is supported by caching HTTP servers such as Varnish. So, for instance, we can use SSI to render a page from HTML with this: HTML <div> <!--#include virtual="/hello-world" --> </div> The virtual keyword makes the webserver request the content from a URL or CGI program. In our case, we would need to set up the webserver to respond to requests based on the path /hello-world with a suitable fragment: HTML <h1>Hello World!</h1> SSR is used in many web frameworks to render the first screen. Additionally, there are also some interesting SSR-specific utilities like compoxure, nodesi, and tailor. Client-side Rendering (CSR) Client-side rendering builds the page in the user’s browser by fetching data from microservices and manipulating the DOM. Most web frameworks use some form of CSR to improve the user's experience. CSR dynamically renders the page on the user’s browser using data provided by the endpoints. The main tools we have to write loosely-coupled components are Custom Elements. Custom elements are part of the HTML standard. They allow us to create new HTML tags and attach logic and behavior to them. Custom elements are dynamically mounted and unmounted from the page using JavaScript: JavaScript // hello-world-component.js class HelloWorld extends HTMLElement { connectedCallback() { this.innerHTML = `<h1>Hello world</h1>`; } } customElements.define('hello-world', HelloWorld); Once defined, we can use the new element like any other HTML tag: HTML <hello-world></hello-world> In the example, the full page would include a script tag to fetch the JavaScript components: HTML <!doctype html> <head> <meta charset="utf-8"> <title>Microservice Example</title> </head> <body> <script src="./hello-world-component.js" async></script> <hello-world></hello-world> </body> While most frontend frameworks can be used for microfrontends, some have been designed specifically for them: Piral: implements isolated components called pilets. Pilets are modules that bundle content and behavior. Ragu: a framework of frameworks. It allows us to embed code written in any framework as widgets. Single SPA: a meta-framework for piecing a UI together using any combination of frontend frameworks like React, Angular, and Ember, among others. Frint: another modular framework for building component-based applications. Integrates with React, Vue, and Preact. Module Federation: a WebPack plugin to create Single Page Applications (SPAs) by bundling separate builds. These builds can be developed independently of each Conclusion Switching to a microfrontend architecture can give our development teams more autonomy, thereby accelerating development. However, the same caveats that apply to microservices are also relevant for microfrontends. We need to have a proven design, which means microfrontends are not a good fit for greenfield projects. New projects are best served by traditional patterns such as single page applications (SPAs) managed by a single team. Only once the frontend has stood the test of time can we consider microfrontends as the way forward.

The Decorator pattern is used to modify the behavior of a target component without changing its definition. This idea turns out to be pretty useful in the context of microservices because it can give you a better separation of concerns. It might even be necessary because the target service might be outside your control. This text looks at how a decorator can be implemented as a service, particularly one that sits between clients and a target service. Example: an E-mail Service Let's introduce an example as a reference for our discussion. Say that we have access to an e-mail service that offers the following API (loosely inspired by this post, which is a nice read about object decorators). It consists of three operations: send an e-mail, list the e-mails of a user, and download the content of an e-mail. We write our examples in Jolie, a service-oriented programming language. interface EmailServiceInterface { RequestResponse: send(SendRequest)(void), listEmails(ListRequest)(EmailInfoList), downloadEmail(DownloadEmailRequest)(Email) } Decorating an Operation Suppose that the e-mail service is available to us as emailService. We want to write a decorator with this logic: whenever send is called, we check if we have sent an “important” e-mail (e.g., the subject contains a specific keyword telling us that the e-mail is important, or the addressee is in a special list); if an important e-mail has been sent successfully, we backup its content by calling another service, for indexing and safe-keeping. Conceptually, we want the following architecture. One way of writing our decorator is to code a service that reimplements all operations offered in interface EmailServiceInterface, as in the following snippet. service EmailServiceDecorator { // Output ports to access the target e-mail service, the backup service, and a library to check if e-mails are important outputPort emailService { ... } outputPort backupService { ... } outputPort important { ... } // Access point for clients inputPort EmailServiceDecorator { location: "socket://localhost:8080" protocol: MyProtocol // e.g., http interfaces: EmailServiceInterface // exposed API } // Implementation main { // Offer three operations: send, listEmails, and downloadEmail [ send( request )( response ) { send@emailService( request )() check@important( { subject = request.subject, to = request.to } )( important ) if( important ) { backup@backupService( request )() } } ] [ listEmails( request )( response ) { listEmails@emailService( request )( response ) } ] [ downloadEmail( request )( response ) { downloadEmail@emailService( request )( response ) } ] } } The code for send does what we have previously described. The code for listEmails and downloadEmail is a pure boilerplate: we’re just forwarding requests and responses between the client and the target e-mail service. Not only is this a bit annoying, but it also means that this approach wouldn't scale well if the target service had many operations. Down With the Boilerplate: Aggregation Building gateways (or proxies, load balancers, caches, etc.) is so natural in a microservice architecture that Jolie offers linguistic constructs to deal with these features effectively. A particularly convenient primitive for creating a decorator is aggregation. In our example, we can rewrite the last code snippet as follows. service EmailServiceDecorator { // Output ports to access the target e-mail service, the backup service, and a library to check if e-mails are important outputPort emailService { ... } outputPort backupService { ... } outputPort important { ... } // Access point for clients inputPort EmailServiceDecorator { location: "socket://localhost:8080" protocol: MyProtocol // e.g., http aggregates: emailServiceInterface // Aggregates instead of interfaces! } main { [ send( request )( response ) { send@emailService( request )() check@important( { subject = request.subject, to = request.to } )( important ) if( important ) { backup@backupService( request )() } } ] } } Notice the usage of the aggregates instruction in the input port. It means that our service is a proxy to the e-mail service now: all client calls to operations offered by the e-mail service are now automatically forwarded to it. Furthermore, we can refine the behavior of specific operations. Here, we defined a custom behavior for the send operation with our logic for backups. No boilerplate anymore! Decorating Multiple Operations Some decorators change the behavior of many operations in a uniform way. For instance, suppose we want to write a decorator that keeps track of all events: whenever an operation is called, we write this in an external log. Here's a naive implementation for our e-mail service (we'll improve on it in a minute). service EmailServiceDecorator { // Output ports to access the target e-mail service and a logger service outputPort emailService { ... } outputPort logger { ... } // Access point for clients inputPort EmailServiceDecorator { location: "socket://localhost:8080" protocol: MyProtocol // e.g., http interfaces: EmailServiceInterface // exposed API } // Implementation main { // Offer three operations: send, listEmails, and downloadEmail [ send( request )( response ) { send@emailService( request )() log@logger( request )() } ] [ listEmails( request )( response ) { listEmails@emailService( request )( response ) log@logger( request )() } ] [ downloadEmail( request )( response ) { downloadEmail@emailService( request )( response ) log@logger( request )() } ] } } Ouch, boilerplate again! Since we're modifying the behavior of every operation, we have to reimplement all of them. However, as already mentioned, the change is uniform: it is the same for all operations. We need the capability of writing that logging code just once and applying it to the entire API of the e-mail service. Jolie offers courier processes that can be applied to entire interfaces to achieve this. Here is what our code can look like by using a courier. service EmailServiceDecorator { // Output ports to access the target e-mail service and a logger service outputPort emailService { ... } outputPort logger { ... } // Access point for clients inputPort EmailServiceDecorator { location: "socket://localhost:8080" protocol: MyProtocol // e.g., http aggregates: emailService // aggregate emailService } // A courier for input port EmailServiceDecorator courier EmailServiceDecorator { [ interface EmailServiceInterface( request )( response ) ] { // Apply to all operations offered by the e-mail service forward( request )( response ) // forward is a primitive: it forwards the message to the aggreated (decorated) service log@logger( request )() } } } No boilerplate again! In a courier, we can receive a message for any operation in a given interface and then use the forward primitive to forward the message to the target service we are decorating. We then invoke the logger. Conclusion People familiar with functional programming might recognize the idea of writing reusable uniform behavior (parametricity, generics, type erasure, etc.). Aggregation and courier processes extend this idea to entire APIs. But even if you're not using a language that supports these features, you can still benefit from the pattern by writing the implementation of each operation by hand. The e-mail example is quite simple. A decorator might generally modify the API by adding or hiding data fields to its types. Jolie supports adding data fields that the decorator can use and are automatically removed by the forward primitive when calls are forwarded to the target service (hiding can be done manually, but a dedicated primitive is planned for future release). An example where data fields are added is a decorator that requires an API key, checks that it's valid, and, if so, forwards the request to the target service (without the API key, which the target service doesn't need to worry about). Dually, an example of a decorator that hides a data field receives calls from a trusted Intranet and automatically injects the necessary credentials to access the target service before forwarding the call.

One of the main reasons to design microservices is that they enforce strong module boundaries. However, the cons of microservices are so huge that it's like chopping off your right hand to learn to write with the left one; there are more manageable (and less painful!) ways to achieve the same result. Even since the microservices craze started, some cooler heads have prevailed. In particular, Oliver Drotbohm, a developer on the Spring framework, has been a long-time proponent of the moduliths alternative. The idea is to keep a monolith but design it around modules. Many flock to microservices because the application they work on resembles a spaghetti platter. If their application were better designed, the pull of microservices wouldn't be so strong. Why Modularity? Modularity is a way to reduce the impact of change on a codebase. It's very similar to how one designs (big) ships. When water continuously leaks into a ship, the latter generally sinks because of the decreasing Archimedes thrust. To avoid a single leak sinking the ship, it's designed around multiple watertight compartments. If one leak happens, it's contained in a single compartment. While it's not ideal, it prevents the ship from sinking, allowing it to reroute to the nearest port where one can repair it. Modularity works similarly: it puts boundaries around parts of the code. This way, the effect of a change is limited to the part and doesn't spread beyond its boundaries. In Java, such parts are known as packages. The parallel with ships stops there because packages must work together to achieve the desired results. Packages cannot be "watertight." The Java language provides visibility modifiers to work across package boundaries. Interestingly, the most famous one, public, allows crossing packages entirely. Designing boundaries that follow the principle of least privilege is a constant effort. Chances are that under the project's pressure in the initial development or with time during maintenance, the effort will slip, and boundaries will decay. We need a more advanced way to enforce boundaries. Modules, Modules Everywhere In the long history of Java, "modules" have been a solution to enforce boundaries. The thing is, there are many definitions of what a module is, even today. OSGi, started in 2000, aimed to provide versioned components that could be safely deployed and undeployed at runtime. It kept the JAR deployment unit but added metadata in its manifest. OSGi was powerful, but developing an OSGi bundle (the name for a module) was complex. Developers paid a higher development cost while the operation team enjoyed the deployment benefits. DevOps had yet to be born; it didn't make OSGi as popular as it could have been. In parallel, Java's architects searched for their path to modularizing the JDK. The approach is much simpler compared to OSGI, as it avoids deployment and versioning concerns. Java modules, introduced in Java 9, limit themselves to the following data: a name, a public API, and dependencies to other modules. Java modules worked well for the JDK but much less for applications because of a chicken-and-egg problem. To be helpful to applications, developers must modularize libraries - not relying on auto-modules. But library developers would do it only if enough application developers would use it. Last time I checked, only half of the 20 common libraries were modularized. On the build side, I need to cite Maven modules. They allow splitting one's code into multiple projects. There are other module systems on the JVM, but these three are the most well-known. A Tentative Approach To Enforce Boundaries As mentioned above, microservices provide the ultimate boundary during development and deployment. They are overkill in most cases. On the other side, there's no denying that projects rot over time. Even the most beautifully crafted one, which values modularity, is bound to become a mess without constant care. We need rules to enforce boundaries, and they need to be treated like tests: when tests fail, one must fix them. Likewise, when one breaks a rule, one must fix it. ArchUnit is a tool to create and enforce rules. One configures the rules and verifies them as tests. Unfortunately, the configuration is time-consuming and must constantly be maintained to provide value. Here's a snippet for a sample application following the Hexagonal architecture principle: Java HexagonalArchitecture.boundedContext("io.reflectoring.buckpal.account") .withDomainLayer("domain") .withAdaptersLayer("adapter") .incoming("in.web") .outgoing("out.persistence") .and() .withApplicationLayer("application") .services("service") .incomingPorts("port.in") .outgoingPorts("port.out") .and() .withConfiguration("configuration") .check(new ClassFileImporter() .importPackages("io.reflectoring.buckpal..")); Note that the HexagonalArchitecture class is a custom-made DSL façade over the ArchUnit API. Overall, ArchUnit is better than nothing, but only marginally so. Its main benefit is automation via tests. It would significantly improve if the architectural rules could be automatically inferred. That's the idea behind the Spring Modulith project. Spring Modulith Spring Modulith is the successor of Oliver Drotbohm's Moduliths project (with a trailing S). It uses both ArchUnit and jMolecules. At the time of this writing, it's experimental. Spring Modulith allows: Documenting the relationships between the packages of a project Restricting certain relationships Testing the restrictions during in tests It requires that one's application uses the Spring Framework: it leverages the latter's understanding of the former, obtained through DI assembly. By default, a Modulith module is a package located at the same level as the SpringBootApplication-annotated class. Plain Text |_ ch.frankel.blog |_ DummyApplication // 1 |_ packagex // 2 | |_ subpackagex // 3 |_ packagey // 2 |_ packagez // 2 |_ subpackagez // 3 #1: Application class #2: Modulith module #3: Not a module By default, a module can access the content of any other module but cannot access subpackages of other modules. C4 Java var modules = ApplicationModules.of(DummyApplication.class); new Documenter(modules).writeModulesAsPlantUml(); To break the build if a module accesses a regular package, call the verify() method in a test. Java var modules = ApplicationModules.of(DummyApplication.class).verify(); A Sample To Play With I've created a sample app to play with: it emulates the home page of an online shop. The home page is generated server-side with Thymeleaf and displays catalog items and a newsfeed. The latter is also accessible via an HTTP API for client-side calls (that I was too lazy to code). Items are displayed with a price, thus requiring a pricing service. Each feature - page, catalog, newsfeed, and pricing - sits in a package, which is viewed as a Spring module. Spring Modulith's documenting feature generates the following: Let's check the design of the pricing feature: The current design has two issues: The PricingRepository is accessible outside of the module The PricingService leaks the Pricing JPA entity We shall fix the design by encapsulating types that shouldn't be exposed. We move the Pricing and PricingRepository types into an internal subfolder of the pricing module: If we call the verify() method, it throws and breaks the build because Pricing is not accessible from outside the pricing module: Plain Text Module 'home' depends on non-exposed type ch.frankel.blog.pricing.internal.Pricing within module 'pricing'! Let's fix the violations with the following changes: Conclusion By toying with a sample application, I did like Spring Modulith. I can see two prominent use cases: documenting an existing application and keeping the design "clean". The latter avoids the "rot" effect of applications over time. This way, we can keep the design as intended and avoid the spaghetti effect. The icing on the cake: it's great when we need to chop one or more features to their deployment unit. It will be a very straightforward move, with no time wasted to untangle dependencies. Spring Modulith provides a huge benefit: delay every impactful architectural decision until the last possible moment. Thanks to Oliver Drotbohm for his review. You can find the source code on GitHub. To Go Further Introducing Spring Modulith Quick start Reference documentation

If you are reading this blog, that means you have heard the terms: APIs and Microservices Development. But many folks have misconceptions that microservices are fine-grained web services or that APIs are equivalent to microservices. These all show fundamental misconceptions, so I created this article to break that out and talk about the key differences between Microservices and APIs. If you are one of them, this article will help you understand the difference between those two concepts. APIs and Microservices both have equal weightage. In this blog, we will understand both APIs and microservices separately, how they both are different from each other, and how they fit together in modern-day web applications. First, Let's Understand What Microservice Is With an Example Microservices is a software architecture that divides an application's features and functionalities into separate and smaller components called services. When this methodology develops an application, it is called microservices architecture. Microservices are trending these days because of their smooth developing process. A microservices architecture makes it easy to develop, integrate and maintain the applications. Initially, developers should build the application step-by-step; later, they can work on each element individually. This process makes adding, fixing, or improving functionality easy without risking the entire application. Microservices architecture is mostly useful for larger enterprises. Example of Microservice As we all know, Amazon is a large online shopping hub and is easy to use. But in the early 2000s, it was tough for Amazon to provide friction-free services. As Amazon's senior product manager described the situation, the Amazon retail website was a large architectural monolith. As all services were tightly connected internally, it was not easy for developers to fix, validate or improve the functionality. With this monolith architecture, Amazon could not meet the scaling requirement of its growing customer base. Amazon broke its monolithic architecture into small independent service components to eliminate these challenges. The Amazon developers' team analyzed the entire application's code and pulled out unit codes that serve similar services. They coupled these units into a web service interface and developed a single service for each section, like a buy button on the product page, tax calculator, checkout button, and so on. Now, Amazon allocated each independent service's ownership to the team of developers so the team could deep dive into the problem and fix it without hindering the whole application. By implementing a microservices architecture, Amazon could achieve the title of the most growing company in the world - valued by market cap at $1.203T on July 19, 2022. If applications are broken up into parts, those individual parts must have a serious need to communicate effectively; therefore, microservices are tied to APIs. Now, Let's See What APIs Are and Their Use An application programming interface (API) is an undetachable part of any application. With the help of APIs, one application can interact with others. In layman's terms, API is the group of protocols that ensure two different applications send, receive, and modify each other's data. APIs are essential in modern application development. It helps in communication between two different applications, which may differ in functionality and construction. APIs help developers access the internal data of an application or its functionality without understanding the whole app's source code. With this feature of APIs - applications, web pages, and other software can communicate and work together. The Use of APIs Many APIs are easily available to improve the software or application's functionality - called public APIs. With the popularity of microservices architecture, the creation of private APIs increased. In this scenario, APIs work as lightweight solutions for individual microservices to interact with each other. Let's understand with a practical example. There are many examples of APIs, but we will take one of them. Let's assume you are planning a world tour and want to book a travel plan. You visit a good website, but you don't have an account for that particular website, but it gives you an option of Google id to log in. How convenient it is! Since Google is a different company from the current travel website, an API enables an interaction between the travel website and Google. First, the travel website uses Google's login API to request your contact information. Next, the Google API acknowledges the request, validates it, fetches the information from its user database, and sends it back to the website. Finally, the website uses your contact information to complete the signing process. This is how APIs help different software to communicate together. I believe this example of APIs will help to understand the basics of its functionality. Types APIs (Public, Partner, Private, and Composite) APIs are widely accepted and used in web-based applications. There are four API types: public, partner, private, and composite. Understanding these four types' differences is important when planning your API design, implementation, and use. Public APIs Businesses with a public API can give outside developers, partners, and businesses free and open access to their applications and data. This allows these partners to build new applications and use data to benefit the business. A public API is an open-source software development interface (SDI) that opens a resource for the use of outside developers, businesses, and organizations. Private APIs An internal API is often used to connect systems and data within an enterprise. These APIs are generally intended for internal use only, and the data should not be publicly accessible or shared with third-party developers. These APIs provide several advantages over public APIs, including a higher level of privacy, less exposure to outside organizations, better control, and fewer data regulations. Partner APIs Partner APIs are a way to provide a high level of access to an organization's data for its business partners in the form of a dedicated API. These partner APIs are only available to specifically selected and authorized outside developers or API consumers and are established through a formal introduction process. The purpose of a partner API is to facilitate business-to-business activities. For example, a business wants to share customer data selectively with outside CRM firms. In that case, a partner API can connect the internal APIs with the partner's portal, creating a secure and transparent channel. Composite APIs It's important to create an API that addresses both simplicity and performance. Creating an API that achieves both these goals can sometimes be difficult. However, combining two or more APIs together becomes a composite API. Composite APIs can often be beneficial because it's often better to have a single API that covers two or more aspects of a process, as it can reduce complexity and improve performance. Category of APIs APIs are the ultimate method of remote software interaction. You can use them to build amazing products and services that work seamlessly across devices and platforms. But if you want your APIs to be successful, they need to be well-designed. Today, there are four API protocols or architectures categories: REST, RPC, WebSocket, and SOAP. And you should use one of these. A Difference Between Microservices and APIs After understanding microservices and APIs separately, let's check some differentiator that makes them distinguishable from each other. Microservices APIs A microservice is an approach that breaks down large silo components into smaller components. An API is a programming interface that helps two or more software to communicate with each other. Creating microservices is easy and takes less time for the developer. Creating and maintaining APIs is a bit difficult as compared to microservices. A developer can create different modules for individual features and functionality with microservices. Whereas APIs help those individual modules communicate with each other without difficulty. It is not possible to access a third-party microservice directly. With the help of third-party API, it is easy to access their services. Microservices are usually designed for solving big and complex problems in the organization. APIs provide a reusable interface that one or more applications can communicate easily. In microservice, using other applications' features and functionality is impossible. Developers can use any third-party application's features and functionality using its API. One microservices has only one API. One API can call different microservices. To keep a long story short, microservices and APIs are significantly different concepts. They are not equivalent and play a completely different roles in web applications. Microservice architecture helps build an application in a more agile framework, whereas APIs provide the essential capabilities for connecting, extending, and integrating software. With the help of APIs, developers can interact with a web application.

Embedding a microservice into another means that a microservice can be run in the same execution context as a parent microservice. Such a mechanism is natively available in Jolie, a service-oriented programming language. Since it is not a native mechanism available in mainstream technologies, it is not widely used. But it allows dealing with microservices from a new and different perspective that opens up new ways for composing them. In this article, I will explain why. What Is Embedding? In the following diagram, the main concept behind embedding is reported. On the left, two microservices are regularly deployed within different execution contexts and they are connected using the network. On the right, the same microservice composition is executed within the execution context of microservice 1 (the parent) and their connection is locally managed. It is worth noting that, in this case, both the microservices are fully defined together with their external interface. Thus they do not require to be manipulated in case they must be separated or aggregated, it is just sufficient to rebind their connection. More services can be embedded into another, and a service that already embeds other services can be embedded again. Moreover, an embedded service can expose its operations outside, if properly configured to do that. In the following example, all the architecture is executed within the execution context of MS1, MS2 and MS3 have their own execution context with microservices MS4, MS5 and microservices MS6, and MS7 embedded respectively. Moreover, both MS1 and MS4 expose operations to be invoked from an external client. Service Architecture Invariance The first consequence of the embedding mechanism in a context of a service-oriented programming paradigm is that the service architecture is invariant with respect to the deployment. I already discussed such a concept in this article where I explained that decisions about the deployment can be postponed thanks to the fact that the deployment can be changed at any time. I think this is a useful consequence of embedding in a service-oriented programming paradigm because it provides a higher level of flexibility at the design time. Dynamic Embedding The dynamic embedding represents the possibility to embed a service at runtime. Such a feature may be used in two different ways: depending on the business logic of the embedder, some functionalities implemented in a different microservice can be run by picking up its definition from a repository. An example of such a scenario, written in Jolie, can be found here: a calculator service dynamically loads the operation to execute embedding the corresponding microservice (sum, sub, div or mul). an external client sends the service definition to be executed to the target microservice. The same example of the calculator, re-implemented exploiting the message passing, can be found here. Dynamic embedding opens the way for a dynamic functional reconfiguration of a microservice, which could be useful in those scenarios where some functionalities must be dynamically updated at runtime or selected and executed depending on the context. A New Perspective for Dealing With Microservice Composition Embedding primitive allows for thinking about microservices in a different way with respect to what we use with traditional technologies because it permits us to treat a microservice as an integral unit of software. Such a fact has two main consequences: a microservice application is not necessarily deployed as a composition of distributed microservices, even if it is always designed as a distributed composition of microservices. A microservice indeed can be deployed as an independent service or it can be used as a library inside another microservice. Such an aspect allows to postpone the decision to deploy all the components as single independent services or as an agglomerate of embedded ones; dynamic embedding opens the possibility to design and implement dynamically reconfigurable microservices that are usually not considered at the design level Conclusions Embedding is a mechanism that allows for achieving some interesting aspects in microservice design and development like postponing deployment decisions and designing dynamically reconfigurable microservices. Moreover, thanks to embedding, developers can design and implement a service-oriented solution by never abandoning the service-oriented programming paradigm. The cognitive effort of the developer is finally reduced because he/she has only to deal with a unique programming paradigm instead of switching from a service-oriented model to another linguistic domain like an object-oriented one. In Jolie, where embedding is natively supported, embedding and related aspects come for free, but if we consider traditional technologies it could be not so easy to figure out how embedding could work. Usually, in fact, a microservice is the engineering combination of a mix of technologies. If we consider the Java stack, for example, the public interface is defined using openAPI, the service endpoints are managed with frameworks like springboot and, finally, the business logic is created using Java. This means that, in a traditional scenario, embedding a microservice should be achieved by embedding all the stack of technologies within the execution environment of a parent microservice, which is not so immediate. On the one hand, this fact allows for a better understanding of the contribution of a natively service-oriented programming language like Jolie is, on the other hand, it could trigger initiatives for adding the embedding mechanics also in traditional microservice technology stacks.

Ahoy, Mateys! It’s been a while since I published my last article on my geo-distributed application development journey. A hot tech conference season put my development on hold, but now I’m back home and ready to share my experience in building a geo-distributed API layer with Kong Gateway. Let me take a moment to review where the project had gotten to. This is what my geo-distributed messenger’s architecture looked like: I managed to automate the deployment of application instances across several cloud regions (to see how the project started and continued, here is a list of all previous articles). However, the application is not a monolith; it’s comprised of several microservices. The Messaging microservice implements the key functionality that every messenger must possess—the ability to send messages across channels and workspaces. The Attachments microservice uploads pictures and other files. Finally, the Reminders microservice comes in handy when a user wants to ignore a message for now but get back to it later. So now, mateys, we reach the question, “What do all microservices need?” Well, they need to talk to each other! Microservices were not born to live in isolation. After following Kong for more than a year, I selected it to create a geo-distributed API layer that can be used as a synchronous communication layer by the microservices. In this article, we’ll review several ways to build a geo-distributed API layer with Kong. My geo-messenger needs an API layer that can withstand various cloud outages (including regional ones) and service requests from the locations closest to the users. So, if you’re still with me on this journey, then, as the pirates used to say, “Weigh Anchor and Hoist the Mizzen!” which means, “Pull up the anchor and get this ship sailing!” Connecting Microservices With Kong Gateway For the sake of simplicity, I’ll use two microservice as an example. A user request always goes to the Messaging microservice first, the key one. But, if the user wants to share a picture in a chat channel, for example, the Messaging microservice delegates this job to its Attachments counterpart. In this case, the Kong Gateway is used as a communication channel. As long as my microservices instances are deployed across multiple cloud regions, I have to go through the same exercise for Kong Gateway. Let’s discuss the options for running Kong in a geo-distributed way. Option #1: Deploying Kong as Sidecar Nearby Microservices The most straightforward way is to deploy Kong Gateway as a sidecar on the same virtual machine (VM) with your microservices. Then you can deploy the VMs with Kong and the microservices across several cloud regions. (NOTE: you can use Kubernetes instead if you like; there are no major architectural differences). In this example, the geo-messenger uses two VM instances—one in the US East and another in the US West. Each VM runs an instance of the microservice and Kong Gateway. In addition, every VM has its own instance of PostgreSQL which is used solely by Kong to store information about microservices and supported routes. Google Cloud Storage and YugabyteDB are geo-distributed by definition. Google Cloud Storage keeps attachments that users upload through the Attachments microservice, while YugabyteDB keeps all other application data (messages, channels, reminders, etc.) The user is connected to the VM closest to their location. In this example, the user is based near New York, so her requests are routed to the VM in the US East region. This is how I achieve the lowest latency possible. If the US East region becomes unavailable due to a region-level outage, then I’ll lose the VM from that region. But the messenger will continue working with no interruptions because the user requests will now be routed to the VM in the US West. Spoiler alert: it’s effortless to automate the deployment and configuration of VMs with microservices and Kong across several cloud locations. The Show, Don’t Tell! Now, let me demonstrate this deployment option. When I start a VM in Google Cloud, the VM executes a special startup script that installs required libraries, builds and runs the microservices, and configures Kong Gateway. These are the steps for Kong setup: Download and install Kong Gateway: Shell echo "deb [trusted=yes] https://download.konghq.com/gateway-3.x-ubuntu-$(lsb_release -sc)/ \ default all" | sudo tee /etc/apt/sources.list.d/kong.list sudo apt-get update sudo apt install --yes --force-yes kong-enterprise-edition=3.0.0.0 Configure Postgres and run Kong migrations: Shell sudo -u postgres psql -c "CREATE USER kong WITH PASSWORD 'password'" sudo -u postgres psql -c "CREATE DATABASE kong OWNER kong" sudo touch /etc/kong/kong.conf echo 'pg_user = kong' | sudo tee --append /etc/kong/kong.conf echo 'pg_password = password' | sudo tee --append /etc/kong/kong.conf echo 'pg_database = kong' | sudo tee --append /etc/kong/kong.conf sudo kong migrations bootstrap -c /etc/kong/kong.conf sudo kong migrations up -c /etc/kong/kong.conf Create a Kong route for attachments uploading: Shell curl -i -X POST \ --url http://localhost:8001/services/ \ --data 'name=attachments-service' \ --data 'url=http://127.0.0.1:8081' curl -i -X POST http://localhost:8001/services/attachments-service/routes \ -d "name=upload-route" \ -d "paths[]=/upload" \ -d "strip_path=false" Note, all IPs are local because Kong runs on the same VM with my microservices. Since you have that startup script that prepares a VM with a required configuration, you need to figure out how to deploy such VMs across multiple cloud regions. Easy! This step can be automated as well: Call this script to create a VM instance template in the regions of your choice. I create templates for US West, Central, and East. Provision VMs with Kong and microservices in all those regions: Shell gcloud compute instance-groups managed create ig-us-west \ --template=template-us-west --size=1 --zone=us-west2-b gcloud compute instance-groups managed create ig-us-central \ --template=template-us-central --size=1 --zone=us-central1-b gcloud compute instance-groups managed create ig-us-east \ --template=template-us-east --size=1 --zone=us-east4-b Next, make sure that the VMs are booted and run normally across the cloud regions: Finally, pick any of the VMs and test the application by uploading a picture into a chat channel. The Messaging microservice calls the configured Kong route to delegate this task to the Attachments microservice. Easy, mateys, isn’t it? Now, let’s review two other alternatives for Kong geo-distributed deployments. Option #2: Kong Standalone Deployment With Shared Database Another approach is better for applications with a significant number of microservices, or that need to deploy microservices and the API layer on separate VMs (or Kubernetes nodes/pods). As the diagram shows, we continue running our application across two cloud regions – US East and West. We also continue using Google Cloud Storage and YugabyteDB for application data and attachments. But now, the microservice and Kong Gateway instances are deployed in standalone VMs. Every microservice and Kong instance is location-aware. For example, when the user from New York wants to share a picture, the request will go to the Messaging instance in the US East (which is closest to the user). Then, that Messaging instance must forward the request to the Attachments service from the same cloud region. This happens by connecting to the Kong instance from US East and calling the /api/us/east/upload API endpoint. That endpoint is a regional one (see /us/east part in the API URL) and is set up to forward requests to the Attachments microservices from US East. Finally, Kong stores all the information about routes and services in a shared instance of PostgreSQL. If you use a PostgreSQL-managed service like Google Cloud SQL, it’s possible to configure PostgreSQL replica instances in a different availability zone. Cloud SQL will failover to the replica if a zone running the primary PostgreSQL instance becomes unavailable. The primary and replica must be in the same cloud region. Presently, Google Cloud SQL doesn’t tolerate region-level outages. Option #3: Kong Standalone Deployment With Distributed Database Deployment option #3 is close to deployment option #2. The only exception is the database where Kong Gateway stores details about routes, services, and other system information. Option #2 used PostgreSQL, while this third option uses Apache Cassandra. Kong supports Apache Cassandra for geo-distributed use cases. A Cassandra cluster can span multiple cloud regions, distributing the load across several distant locations and withstanding region-level outages that are not supported by Google Cloud SQL (managed PostgreSQL). However, starting with Kong 4.0, PostgreSQL will be the only officially supported database. The Cassandra integration is already deprecated. The Kong community will likely find a replacement for Cassandra in the foreseeable future. And that replacement might be YugabyteDB, which is built on the PostgreSQL source code and frequently referred to as distributed PostgreSQL. What’s on the Horizon? Alright, mateys! Now I’ve got my microservices and API layer working across multiple cloud regions, what’s next? Well, I need to figure out how to configure the Global Cloud Load Balancer that intercepts user requests at the nearest PoP (point-of-presence) and then routes the requests to one of my application instances (VMs). Follow me to be notified as soon as the next update is published! And check out the previous articles in my development journey.