Microservices architecture is a better approach than the monolith approach to application development. The question is, how do you pull it off?
One extremely beneficial method is the 12-factor app methodology. It was created by developers at Heroku back in 2011. So let’s get started.
The 12-factor methodology is a set of 12 best practices for developing applications to run as services. The 12-factor app principles became very popular because they align with the microservices principle. Let’s look at each of them.
The first one is the codebase. This principle states that an app should be tracked in a single code repository and must not be shared with any other application. Usually in microservices, every services have their own codebase. And having an independent codebase helps you to ease the CI/CD process for your applications.
The next one is dependencies. All application packages should be managed using package managers such as SBT, Maven, or Gradle. For example, Maven requires us to describe a project’s dependencies in an XML file, typically called the Project Object Model (POM). Again, in a non-containerized environment, you can use configuration management tools like Chef, Ansible, and so on to install system-level dependencies. But for a containerized environment, you can always use a Dockerfile.
Configuration: Configuration says that you must externalize configuration from the application. All configuration data should be stored separately from the code in the environment as variables, not in the code repository, and read by the code at runtime. Having a separate config file makes it easy to update config values without touching the codebase, eliminating the need to redeploy applications when the values change. You can use configuration management tools like Ansible or Chef to automate this process.
Backing services– a 12-factor app can automatically swap the application from one provider to another without making any further modifications to the codebase. Let us say you would like to change the database server from on-premises MySQL to OCI Database Cloud Service. To do so, you should not make any code changes to your application. Only a configuration change should be able to address it.
Build, release, and run– strictly separating the build and run stages is what this factor promotes. You can use the CI/CD tools to automate the build and deployment process. Docker images make it easy to separate the build, release, and run stages more efficiently. Images should be created from every commit and treated as a deployment artifact.
Processes — by adopting the stateless nature of REST, your services can be horizontally scaled as needed with zero impact. If your system still requires maintaining state, you can use resources like Redis, Memcached, or DataStore to store it instead of in memory. Never assume that any caged-in memory or on-disk will be available during the feature request or job.
Port binding —the application should be self-contained rather than deployed to any external web server. To make the port-binding factor more useful for microservices, you must allow access to a service’s persistent data only through its service APIs. This prevents implicit service contracts between microservices.
Concurrency —this principle advocates horizontal scaling over vertical scaling. While vertical scaling requires adding hardware to the system, horizontal scaling adds additional application instances. In a microservices architecture, adopting containerization enables applications to be scaled horizontally as demand increases.
Disposability —the system should not be impacted when new instances are added or existing ones are taken down. This is known as system disposability. Systems do crash due to various reasons. The system should ensure that the impact is minimal and that the application is stored in a valid state. Services deployed in Docker containers do this automatically, as it’s an inherent feature of containers that they can be stopped and started instantly.
Development and production parity —you must always keep development, staging, and production as similar as possible to avoid the risk of bugs showing up in the later stages of your software development lifecycle. Containers work well for this, as they enable you to run the exact same execution environment from local development through production.
Logs —logs become paramount for troubleshooting production issues and understanding user behavior. Log provides visibility into the behavior of a running application. Logs should be streamed to a chosen location rather than dumped into a log file. Observability and monitoring help you achieve this in a microservices-based architecture, which we will also be covering in our later modules.
Admin processes —the idea here is to separate administrative tasks from the rest of the app to prevent one task from causing issues with your running applications. For example, performing data cleanup, running analytics for a presentation, or turning features on and off for A/B testing.
After understanding microservices and the differences between microservices and monolithic architecture, let us also look at the top benefits of microservices. The primary benefit of microservice architecture is its loosely coupled components. These components can easily be developed, replaced, and scaled individually.
Microservices are not organized around technical capabilities of a particular product but rather business capabilities, as the end goal is user experience and customer satisfaction. As with microservices, the choice of programming language can be multilingual. Also, development teams can work in parallel on different parts of the code. It improves the productivity and, at the same time, the speed of deployment.
Increased fault tolerance and fault isolation —microservices offer fallback mechanisms so that, if one microservice fails, the surrounding microservices aren’t affected and can still make progress. Greater scalability and flexibility– this is one of the important features that microservices offer– its ability to scale horizontally. This means that any deployed service can be duplicated to avoid slow-execution bottlenecks.
Simplified security monitoring– the ability to isolate each service facilitates better security management and monitoring. It’s always easier to isolate threats with the modular arrangement. Autonomous, cross-functional teams —specific microservices can be assigned to specific development teams, allowing them to focus solely on one service or feature. This means teams can work autonomously without worrying about what’s going on with the rest of the application.
Let’s take a look at some of the drawbacks of microservices design. Microservice designs are more complex. Communication between services can be complex at times. An application can include dozens or even hundreds of different services, and they all need to communicate securely.
More expensive than monoliths– for microservices architecture to work for your organization, you need sufficient hosting infrastructure with security and maintenance support. You also need skilled development teams who will understand and manage all of these services for you. Any microservice initiative requires organizations to change their internal culture. Before they can start the migration process, there should already be a mature, agile, and DevOps culture in place.
Microservice’s design presents harder debugging problems. Debugging becomes more challenging with microservices. With an application comprising multiple microservices, each with its own set of logs, tracing the source of the problem can be difficult at times.
Global testing is difficult. While unit testing may be easier with microservices, integration testing is not. The components are distributed, so developers can’t test the entire system on their individual machines.
To wrap up, clearly, there are many advantages and disadvantages of microservices architecture to consider. But it’s important to consider how well this approach fits your organizational culture and goals. Implementing microservices can deliver significant benefits, particularly for large companies or complex business domains.
Recent Comments