Microservices

"Microservices" is the tech jargon that is used by everyone these day but only few have the clear understanding what they really are.

The first questions that arises into our mind is "Why we need Microservices?"

Before we dig deeper in to the above question let us understand what is Monolithic Architecture. Monolithic means composed in one piece. A Monolithic application is the one in which all component must be present for the application to work. When I am talking about component I mean the presentation, business and data (layer of 3 tier arch). This poses a serious challenge of rebuilding and redeployment of the whole application even if there is a small change in a particular component.

In contrast to Monolith architecture Microservices provides an architectural style where the entire application is divided into loosely coupled, independent service as opposed to the monolithic approach of a large, tightly coupled application.

The main idea behind a microservice architecture is that applications are simpler to build and maintain when broken down into smaller pieces that work seamlessly together. When using microservices, you isolate software functionality into multiple independent modules that are individually responsible for performing precisely defined, standalone tasks. These modules communicate with each other through simple, universally accessible application programming interfaces (APIs).

Applications built using microservices possess certain characteristics. In particular, they:

• Are fragmented into multiple modular, loosely coupled components, each of which performs a discrete function
• Have those individual functions built to align to business capabilities
• Can be distributed across clouds and data centers
• Treat each function as an independent service that can be changed, updated, or deleted without disrupting the rest of the application

Microservice architectures let you split applications into distinct independent services, each managed by individual groups within your software development organization. They support the separation of responsibilities critical for building highly scaled applications, allowing work to be done independently on individual services without impacting the work of other developers in other groups working on the same overall application.

In short, your application can grow as your company and its requirements grow. Your application looks more like this:

This diagram shows an application constructed as a series of microservices. As you can see, each microservice has a clear team owner, and each team has a clear, non-overlapping set of responsibilities. In practice, however, some services may come from third-parties, connected via APIs, and may not be totally visible to the application owner.

Key enabling technologies and tools

While just about any modern tool or language can be used in a microservices architecture, there are a handful of core tools that have become essential and borderline definitional to microservices:

Containers, Docker, and Kubernetes

One of the key elements of a microservice is that it’s generally pretty small. (There is no arbitrary amount of code that determines whether something is or isn’t a microservice, but “micro” is right there in the name.) When Docker ushered in the modern container era in 2013, it also introduced the compute model that would become most closely associated with microservices. Because individual containers don’t have the overhead of their own operating system, they are smaller and lighter weight than traditional virtual machines and can spin up and down more quickly, making them a perfect match for the smaller and lighter weight services found within microservices architectures.

With the proliferation of services and containers, orchestrating and managing large groups of containers quickly became one of the critical challenges. Kubernetes has emerged as one of the most popular container orchestration technologies in the world because it does that job so well.

API gateways

Microservices often communicate via API, especially when first establishing state. While it’s true that clients and services can communicate with one another directly, API gateways are often a useful intermediary layer, especially as the number of services in an application grows over time. An API gateway acts as a reverse proxy for clients by routing requests, fanning out requests across multiple services, and providing additional security and authentication.

There are multiple technologies that can be used to implement API gateways, including API management platforms, but if the microservices architecture is being implemented using containers and Kubernetes, the gateway is typically implemented using Ingress or, more recently, Istio.

Messaging

While best practice might be to design stateless services, state nonetheless exists and services need to be aware of it. And while an API call is often an effective way of initially establishing state for a given service, it’s not a particularly effective way of staying up to date. A constant polling, “are we there yet?” approach to keeping services current simply isn’t practical.

Instead, it is necessary to couple state-establishing API calls with messaging or event streaming so that services can broadcast changes in state and other interested parties can listen for those changes and adjust accordingly. This job is likely best suited to a general-purpose message broker, but there are cases where an event streaming platform, such as Apache Kafka, might be a good fit.

Serverless

Serverless architectures take some of the core cloud and microservices patterns to their logical conclusion. In the case of serverless, the unit of execution is not just a small service, but a function, which can often be just a few lines of code. The line separating a serverless function from a microservice is a blurry one, but functions are commonly understood to be even smaller than a microservice.

Where serverless architectures and Functions-as-a-Service (FaaS) platforms share affinity with microservices is that they are both interested in creating smaller units of deployment and scaling precisely with demand.

Key benefits of Microservices

According to a recent survey by leanIX, organizations using microservices get new software to market five times faster than those that don’t. Most companies using microservices are so satisfied with the results that they plan to continue using them in the next six months. And 71% of them plan to increase their use of microservices in the next 12 months

The top 10 benefits that organizations realize from deploying microservices include:

1.     Improved scalability. Because microservices let you independently scale services up or down, the ease—and cost—of scaling is dramatically less than in a monolithic system. Adding new capabilities usually means adding discrete new microservices, not redoing the entire application, which increases both development speed and application stability.

2.     Better fault isolation. If one microservice fails, all the others will likely continue to work. This is a key part of the microservices architectural design.

3.     Optimized scaling decisions.With microservice architectures, scaling decisions can be made at a more granular level, allowing more efficient system optimization and organization.

4.     Localized complexity. Microservice architectures let developers think about services as black boxes. Owners of the service need to understand the complexity of only what is within their service. Other service owners need to know only what capabilities a service provides, without having to worry about how it works internally. This compartmentalization of knowledge and complexity makes it easier to create and manage large applications.

5.     Increased business agility. Microservices are relatively small and simple, and failure of a microservice affects only that service—not the whole application—so enterprises can afford to experiment with new processes, algorithms, and business logic. Microservices give you the freedom to experiment and “fail fast.”

6.     Increased developer productivity. New developers can get up to speed rapidly, since it’s easier to understand a small, isolated piece of functionality than an entire monolithic application.

7.     Simplified debugging and maintenance. For the same reasons that building individual microservices is easier than coding for a monolithic architecture, developers can be much more productive when debugging code and performing maintenance.

8.     Better alignment of developers with business users. Since microservice architectures are organized around business capabilities, developers can more easily understand the user perspective and create microservices that are better aligned with the business.

9.     Future-proofed applications. When innovations happen and new or updated technology disrupt your software development process, microservice architectures makes it easier to respond by replacing or upgrading the individual services affected without impacting the whole application.

10. Smaller and more agile development teams. In modern software organizations, teams are often organized by the microservices they work on. These teams involve fewer people, and they’re more focused on the task at hand. Jeff Bezos’s famous “two pizza rule”—claiming that a software team that couldn’t be fed with two pizzas was too big—fits perfectly into the microservices philosophy.

Potential drawbacks of Microservices

Nothing is free, however, and microservice architectures do carry their own costs.

1.     Microservice architectures can be complex. While individual microservices may be easier to understand and manage, the application as a whole may end up with significantly more moving parts. There are often more components involved, and those components have more interconnections. Those interdependencies increase the application’s overall complexity, which can create problems.

2.     A microservices approach requires careful planning. Because all the microservices in an application must work together, developers and software architects must carefully plan out how to break down all the functionality and dependencies. You can also run into data challenges when starting an application from scratch or modifying a legacy monolithic app. In addition to carefully mapping out individual microservices, multiple iterations can be required until you get it right.

3.     Proper sizing of microservices is critical, and hard to calculate. If you make your microservices too big, you can end up with all the drawbacks of monoliths. If you make them too small, you move the complexity out of the individual services and into the dependency maps, which makes the application harder to understand and manage at scale. Worse, dealing with complex dependencies typically requires more experienced—and higher paid—developers and architects.

4.     You may have little control over third-party microservices. Many microservices architectures include services from third-parties, maintained by teams that you don’t have access to. Third-party services can change their APIs (or dependencies) at any time—and in ways that may break your application. If they do modify their APIs, you need to know and be able to respond ASAP.

5.     Downstream dependencies are difficult to track. One key to microservice success is to limit interdependencies and carefully track ones that you can’t avoid. The application must be able to survive failures of individual microservices, yet downstream problems often happen, and can cascade through the ecosystem. Building fault-tolerance into an application built with microservices can be more complex than doing so in a monolithic system.

6.     Multiple microservices may offer bad actors more opportunities. As microservices grow in popularity, they may increase your applications’ vulnerability to hackers and cybercriminals. Because microservice architectures allows you to use multiple operating systems and languages when building an application, there’s the possibility of having more “soft targets” for malicious intrusions. In addition, you may not have visibility into the vulnerabilities or behaviour of third-party services used by your applications.

Microservices, when used effectively, pay off

Used effectively, microservice architectures allow you to scale your application as the number of developers working on your application increases. The key is to build applications without creating a complex, unwieldy beast at the macro level. That means keep tracking each time a new service is added to your system or a new connection between microservices is made.

It also means examining the complexity increase and making sure it is warranted and well understood. Regularly examining the entire application system is critical to keep an interconnected set of microservices working effectively and reliably.


For microservices development and maintainence  avail our Application Development Service.