A microservice architecture describes an application that is a collection of smaller autonomous, loosely coupled services, which can be managed, maintained, and tested by a small team. This makes it possible for developers to make changes to a service and redeploy it without affecting the entire application. It also allows developers to work in a variety of programming languages—as each service is discrete and interacts with the other services through APIs.
But things weren’t always so easy…
Traditionally, developers built software applications as a unified structure that was self-contained; a single computing network with a single codebase that integrated myriad smaller applications. This was an easy and convenient build, and still is, especially during the initial stages of a project’s life cycle. It allows easier code management, and deployment. It enables a higher speed of development as a result of the simplicity that comes from utilizing one single code base. This led to monolithic architecture becoming the norm. The problems began when applications grew to a size that complicated scaling. Making any change to an application of this size called for the entire stack to be completely updated. To make a single change to a single function called for the stopping of the entire program as developers updated the function and tested it. Developers were forced to build a similar but updated version of the application. This was time-consuming, and resource-intensive and it made deployment a challenge.
Clearly, a disruption was needed.
Disadvantages of a Monolithic Architecture
Slow development speed: The size of a monolithic application hampers development, increases complexity, and slows down the entire development and release process. This makes it complicated, time-intensive, and expensive to implement new features and functions
The key disadvantages can be summarized as follows:
Scalability: Individual components cannot be scaled; the entire structure has to be scaled up, which is an added cost factor.
Reliability: An error in any module impacts the entire application.
Time to release: Any small change would need a complete regression cycle would mean increased time to test and so to release.
Deployment: Any change, no matter how small, requires the redeployment of the entire monolithic application.
Disrupting the Monolith Approach
Then in 2009, a large and growing OTT streaming company did something revolutionary. In a bid to meet the demand for the explosive growth of its video streaming services, the company migrated its entire IT to a public cloud and switched from its monolithic architecture to a structure where services were broken up into smaller individual and autonomous components. In effect, microservices. This was even before the term ‘microservices’ came into being.
That company was Netflix.
Netflix now has thousands of microservices that manage and support separate parts of its platform. And Netflix’s engineers deploy code frequently, possibly a thousand times a day. This just would not have been possible with the earlier monolithic build.
Advantage: Microservices
To repeat, the microservices architecture, (or simply, microservices) relies on a series of independently testable and deployable services. Each of the services points to a specific purpose or goal. They have their own business logic and database. When needed, updates, tests, scaling, and deployment happen within each service.
By decoupling major business applications into separate, independent code bases, Microservices makes it easier to manage.
It must be pointed out that Microservices don’t actually reduce complexity. What they do do is make complexity more manageable by splitting tasks into smaller processes that function independently of each other, while continuing to contribute to the overall whole.
This is a huge advantage for DevOps too, as the continuous delivery practice that defines DevOps, aligns with the discrete, de-coupled, autonomous nature of a microservices architecture, allowing teams to adapt quickly to user requirements. In addition, microservices enable a continuous integration and continuous delivery (CI/CD) approach, as developers can now experiment with code and quickly roll changes back if they don’t work as intended.
Microservices resolve a variety of headaches for businesses. Since each of the microservices units run independently, they can be developed, updated, deployed, and scaled without impacting the other services. This also means avoiding duplicate functionality development across the org, other groups and orgs can just use the required microservice. It enables more frequent software updates and improves reliability, uptime, and performance. From deploying updates weekly or even longer, they can now be done multiple times a day. This allows companies to deliver greater value to their customers, faster, and more cost-effectively.
Building robust inter-microservices communicability:
For a microservices architecture to function optimally, individual services need to communicate with each other. APIs enable this communication, without it we would just have a collection of disconnected microservices. The alternative is to use a direct client to microservice communication approach. Here, each microservice would have a public endpoint—which would otherwise reside on the API. This would allow a client application to send its requests directly to a particular microservice. This approach might work for a small microservices application, but with large, complex microservices-based architectures, there are some issues that might occur, such as increased latency and complexity, cross-cutting concerns, inability to communicate with services that use non-Internet protocols (like AMQP, or binary).
In such instances, API gateways offer a more functional solution for large or complex applications. It provides a single entry point (aka, backend for frontend). The gateway offers an intermediate layer that makes it convenient for microservice-based application connectivity, avoiding issues such as
- coupling (where client apps are coupled to microservices)
- multiple round trips (increased latency)
- security issues (without a gateway the microservices will be exposed, offering a larger vulnerable surface); cross cutting.
SLS API Generator
Applied AI uses SLS API Generator to enable configuration and development of microservices APIs without the tedium of writing production code for the API, using Dont Repeat Yourself (DRY) patterns. The tool can generate serverless code along with unit test cases as well as CI/CD pipeline —as per your entity definition.. The generated code can be modified by users as per their business logic and then deployed using the generated pipeline.
SLS API Generator Benefits
- Speedy development of new services for the entity
- Ease in modifying code, as per business logic
- Use of pre-written test cases to save unit testing time
- Code uniformity, standardization (use of standard libraries)
- Lean code that conforms to DRY norms, and coding best practices
Usage of the SLS API Generator is an important differentiator which helps us to develop production quality serverless APIs for you quickly. Post the Entity/Object Model design it takes us just days to get those APIs deployed with a very good unit-test coverage.
Also read: Components of a microservices architecture
Microservices Advantages:
Agility: Small, independent teams can build and deploy quickly and frequently, which promotes agility.
Flexible scaling: Like a monolithic application, microservices too can reach load capacity. The difference is that when and if this happens new instances of that service can be deployed quickly, relieving pressure. As a multi-tenant and stateless entity with customers spread across multiple instances, it can support significantly larger instances.
Continuous deployment: Release cycles are now faster and more frequent. Updates can happen multiple times a day, instead of weekly or longer. Very good test coverage improves this speed further.
Highly maintainable and testable: Being able to experiment with new features, and roll back if they don’t perform as intended, makes it easier to update code, isolate bugs and fix them. And it reduces time-to-market for new features.
Independently deployable: As microservices are individual (independent) units they can be quickly deployed.
Technology flexibility: The autonomy and independent nature of microservice architectures gives teams the freedom to select the tools they desire.
High reliability. Changes can be made to a specific service without bringing down the entire application.
All these advantages do not make microservices the ideal one-size-fits-all solution. Not all organizations can—or should—implement microservices. Moving from the monolithic architecture’s one, or a small number of codebases microservices, which require many more distributed systems and services, can give rise to unintended complexity, and can reduce the speed and flexibility that microservices were designed to deliver. Plus, it can be a challenge to determine how the application’s sub-services should be split, how different components relate to each other, who owns a particular software component, etc.
Thus, smaller companies—a single product company, for instance—would not need a microservices architecture at all.
Typical Disadvantages
Development sprawl: Compared to monolithic services, microservices add complexity, as there are more services in more places created by multiple teams. This results in slower development speed and sub-optimal operational performance.
Higher infrastructure costs: Every new microservice comes with its own set of requirements, such as test suite/s, deployment playbooks, hosting infrastructure, monitoring tools, etc., which can bring up costs significantly. (Going serverless would help immensely in this though).
Organizational challenges: Development teams need to communicate, and collaborate to effectively coordinate updates, which adds another level of communication.
Debugging challenges: Every microservice has its own logs. This makes debugging more complicated. Plus, if a single business process runs across multiple machines, debugging will be further complicated.
Lack of standardization: Autonomy is good, but it can also lead to a proliferation of languages, logging standards, and monitoring.
Lack of clear ownership: The addition of more services will also increase the number of teams running those services. At times it can become difficult to identify the available services a team can leverage or whom to contact for support.
Recognizing the Need to Migrate to a Microservices Architecture
Most projects initially start out as monolithic and over time, as new features are added, evolve into a microservice architecture.
When this happens it may start to become cumbersome to have many developers working on a single codebase.
Code conflicts will also arise more frequently; plus there is a greater risk of updates to one feature introducing bugs in an unrelated feature.
When and if you notice these undesirable patterns, it might be time for your company to consider migrating to microservices.
Unsure if and how your organization can benefit from microservices? Reach out to our team for a no-commitment presentation, at your convenience.
