When someone ask from IT people “Build me some microservices, make it happen!”
So, let’s start from the bottom line.
What do they mean by the word “Microservices”?
Microservice architecture, or simply microservices, is a distinctive method of developing software systems that tries to focus on building single-function modules with well-defined interfaces and operations. The trend has grown popular in recent years as Enterprises look to become more Agile and move towards a DevOps and continuous testing.
Key Features of Microservices.
The code of each microservice is stored in an isolated archive, runs its own memory space, and functions independently.
Communication between services is a bit more complex since developers should use logic to connect them and deal with failures that sometimes occur.
Multiple iterations don’t increase the application size.
The scaling of one component is possible.
A shared library can be used.
Continuous delivery can be easily performed.
Microservices Tools
1) Wiremock: Testing Microservices. WireMock is a flexible library for stubbing and mocking web services. It can configure the response returned by the HTTP API when it receives a specific request. It is also y used for testing Microservices.
2) Docker: Docker is open source project that allows us to create, deploy, and run applications by using containers. By using these containers, developers can run an application as a single package. It allows you to ship libraries and other dependencies in one package.
3) Hystrix: Hystrix is a fault tolerance java library. This tool is designed to separate points of access to remote services, systems, and 3rd-party libraries in a distributed environment like Microservices. It improves overall system by isolating the failing services and preventing the cascading effect of failures.
Before moving to the tips, first let’s define what we mean by “Monolith” and “Microservice”. A monolithic architecture is built as one large system and is usually one code-base. A monolith is often deployed all at once, both front and end code together, regardless of what was changed. A microservices architecture however is where an app is built as a suite of small services, each with their own code-base. These services are built around specific capabilities and are usually independently deployable.
Lets discuss why we are failing.
1. Use a HR driven Architecture
Microservices are also a great example of where humans enter the picture. We cannot understand systems without taking into account people, because they are an integral part providing not only input, but feedback (and modification). It’s a symbiosis. Microservices are an example of how you can break things down to smaller, more manageable pieces in order to scale the human.
This is a service-oriented architecture pattern wherein applications are built as a collection of various smallest independent service units. It is a software engineering approach that focuses on decomposing an application into single-function modules with well-defined interfaces. These modules can be independently deployed and operated by small teams that own the entire lifecycle of the service.
2. The Monolithic Business
In the course of time, the solution is developing, the application scope is increasing, and the overall structure becomes blurred. When the entire code looks like a lump of mud, it’s hard to discern some features, dependencies, or side-effects, especially for new developers that join the team. It’s also a challenge to make changes properly and quickly in a large and complicated app in which everything is tightly coupled and mutually dependent. Therefore it is difficult to understand and change.
Every small change requires full redeployment of the entire application, even if only one piece of functionality needs to be updated. It means that all the developers have to wait in order to see the impact of a tiny change. This is a great obstacle when multiple teams are working on the project. The team agility and the frequency of new deliveries are reduced.
Barrier to new technologies and barrier to continuous delivery/deployment/integration. Adoption of a new technology may turn into a nightmare for a company, as it will affect the entire system, take a long time and cost too much. At the same time, an enterprise will definitely lose a position in the market without implementing new technologies. Continuous delivery implies that software is incrementally developed and updated multiple times a day. In case of a monolith, it is almost an impossible task, as every change lead to the whole system redeployment. Today, a large company can’t be efficient enough and stay the course without CD implementation.
The large size of a codebase overloads IDE increases development time and slows down the start-up time. One bug in the system can potentially stop the entire process, as all of the components are interconnected. This can be identified as poor reliability.
3. The Decision Monolith
You may be building your software application from scratch by using Microservices Architecture, or you may be converting existing applications/services into microservices. Either way, it is quite important that you properly decide the size, scope, and capabilities of the Microservices. Probably, that is the hardest thing that you initially encounter when you implement Microservices Architecture in practice.
Let's discuss some of the key practical concerns and misconceptions related to the size, scope, and capabilities of microservices.
Lines of Code/Team size are lousy metrics: There are several discussions on deciding the size of the Microservices based on the lines-of-code of its implementation or its team's size. However, these are considered to be very impractical and lousy metrics, because we can still develop services with less code but totally violating the microservice architectural principals.
"Micro" is a bit misleading term: Most developers tend to think that they should try to make the service as small as possible. This is a misconception.
Guidelines for Designing Microservices
· Single Responsibility Principle(SRP): Having a limited and focused business scope for a microservice helps us to meet agility in development and delivery of services.
· During the designing phase of the microservices, we should find their boundaries and align them with business capabilities (also known as bounded context in Domain-Driven-Design).
· Make sure the microservices design ensures the agile/independent development and deployment of the service.
· Our focus should be on the scope of the microservice but not about making the service smaller. The (right) size of the service should be the required size to facilitate a given business capability.
· Unlike service in SOA, a given microservice should have very few operations/functionalities and a simple message format.
· It is often a good practice to start with relatively broad service boundaries to begin with and then refactor to smaller ones (based on business requirements) as time goes on.
4. The SPA Monolith
The techniques involved in creating modern web applications are continually evolving. It can be difficult to separate out the ones that are truly improving how web applications are developed from those experiments that, while often interesting, are ultimately not worth investing in. From this sea of ideas a couple of trends have risen to the top and are radically changing how web applications are developed. These techniques are microservice-based architectures on the server and single page applications (SPAs) on the client. While an initial review of these two techniques doesn’t reveal any relation, a deeper analysis shows that these two trends are actually great partners and can be combined to enable powerful, yet maintainable, applications to be created.
One of the side effects of how a single page application works is that it tends to change the type of information that the client-side application is seeking. Older style client-side applications would send data back to the server and expect pre-processed HTML back. Single page applications, however, tend to send and receive pure data streams. The SPA will then interpret the response and create the appropriate presentation of that data to the user. This change removes the requirement from the server to provide the context for the data, making it more portable and reusable. Extending this reasoning further, it becomes much simpler for a SPA to consume data from multiple sources without those sources knowing how the data will be used and, thus, makes them prime candidates for consuming microservices directly. This is especially true in enterprise environments where cross-application resource sharing (aka CORS) enables a SPA to use data from microservices that are hosted in different domains. This allows an application’s server-side to become even simpler: it simply delivers the assets that the SPA requires and it gathers the data that it needs independently.
5. The Distributed Monolith
I believe that many of the problems that people run into with small and medium sized monoliths can be alleviated by having a good automated test suite and automated deployments. Having a single, non-distributed codebase can be a huge advantage when starting out with a new system. It allows you to more easily reason about your code, allows you to more easily test your code, and it allows you to move quickly and change quickly without having to worry about orchestration between services, distributed monitoring, keeping your services in sync, eventual consistency, all of the things you’ll run into with microservices. Things that might not seem like huge challenges at first glance, but in reality are huge hurdles to overcome.
As the system size and developer count gets larger, you’ll find that splitting out services will become commonplace. You hear about companies like Netflix or Uber that have hundreds of microservices in their ecosystems. These companies are at the extreme end of the scale. They have thousands of developers and are often deploying thousands of times per day. They need tons of fine-grained services in order to make any of this sane and manageable. But what they might think of as a fine-grained service is probably a medium sized application to a much smaller company. That is something that is important to keep in mind, the scale of some of the systems that are successfully deploying large numbers of microservices.
6. Think of the meat cloud
Microservices are not necessarily exclusively relevant to cloud computing but there are a few important reasons why they so frequently go together—reasons that go beyond microservices being a popular architectural style for new applications and the cloud being a popular hosting destination for new applications.
Among the primary benefits of microservices architecture are the utilization and cost benefits associated with deploying and scaling components individually. While these benefits would still be present to some extent with on-premises infrastructure, the combination of small, independently scalable components coupled with on-demand, pay-per-use infrastructure is where real cost optimizations can be found.
Secondly, and perhaps more importantly, another primary benefit of microservices is that each individual component can adopt the stack best suited to its specific job. Stack proliferation can lead to serious complexity and overhead when you manage it yourself but consuming the supporting stack as cloud services can dramatically minimize management challenges. Put another way, while it’s not impossible to roll your own microservices infrastructure, it’s not advisable, especially when just starting out.
CI/CD: Continuous Integration and Continuous Development is a modern development practice which merges development with testing, allowing developers to build code collaboratively, submit it to the master branch, and checked for issues. This allows developers to not only build their code but also test their code in any environment type and as often as possible to catch bugs early in the applications development lifecycle
7. The Home-Grown Monolith
“If you wish to make MICROSERVICES from scratch, you must first create a FRAMEWORK”
Homemade event sourcing: Event sourcing is a great way to atomically update state and publish events. The traditional way to persist an entity is to save its current state. Event sourcing uses a radically different, event-centric approach to persistence. A business object is persisted by storing a sequence of state changing events. Whenever an object’s state changes, a new event is appended to the sequence of events. Since that is one operation it is inherently atomic. An entity’s current state is reconstructed by replaying its events.
Events: User action, API calls, callbacks (webhooks), recurring cron jobs can all generate Events. Events are persisted and immutable.
Version increase, runtime surprise, change the world event can be happened.
Microservices Make Promises. The purpose of a promise is to describe that behavior and be able to break it down into constituent parts. It provides a language for systems that allows us to describe the elements of a system and what happens when you put them together, like atoms into molecules. Microservices are a modern incarnation of this idea.
There are two ends of a promise: the offer of a service and the acceptance of it. You may choose to accept less than is offered. This is another way of talking about autonomy of the actors in a system. It’s also a good representation of how the world actually works. You simply cannot force your will onto another actor, or device, without attacking it in some way. Ultimately, it’s up to that agent to act the way you want. This drives you to understand all the communications pathways in a system and exposes all the failure modes that can manifest.
Cross-cutting dependencies as social tools Job insurance via invasive frameworks Building frameworks is fun! Try it! Ideas: Collections, String-Utils, Logging, ORM!
8. The event Monolith
Marketing Pitch: Below figure describes all about the term.
Event sourcing marketing pitch: Event sourcing Marketing Pitch Audit trail - Immutable history for free Distributed data management Decoupled microservices with CQRS and much more!
One of the trickiest problems with microservices is dealing with data as it becomes spread across many different bounded contexts. An event architecture and event-streaming platform like Kafka provide a respite to this problem. Event-first thinking has a plethora of other advantages too, pulling in concepts from event sourcing, stream processing, and domain-driven design.
9. The Data Monolith
Microservices work best when we practice information hiding, which in turn typically leads us toward microservices totally encapsulating their own data storage and retrieval mechanisms. This leads us to the conclusion that when migrating toward a microservice architecture, we need to split our monolith’s database apart if we want to get the best out of the transition.
there are a number of issues related to sharing a single database among multiple services. The major issue, though, is that we deny ourselves the opportunity to decide what is shared and what is hidden—which flies in the face of our drive toward information hiding. This means it can be difficult to understand what parts of a schema can be changed safely. Knowing an external party can access your database is one thing, but not knowing what part of your schema they use is another. This can be mitigated through the use of views, which we’ll discuss shortly, but it’s not a total solution.A nother issue is that it becomes unclear as to who “controls” the data. Where is the business logic that manipulates this data? Is it now spread across services? That in turn implies a lack of cohesion of business logic. As we discussed previously, when thinking about a microservice as being a combination of behavior and state, encapsulating one or more state machines. If the behavior that changes this state is now spread around the system, making sure this state machine can be properly implemented is a tricky issue.
10. Go Full-Scale-Polyglot
For the uninitiated, A Polyglot programmer is a person who can write valid computer programs which do the same thing, in many programming languages.
What is Waldo?
Polyglot: The idea behind polyglot microservices is to let a team which is responsible for a certain set of services decide which tech stack they are going to use to solve the problems. At first, this sounds fine. The devs can work in their favourite stack, get more autonomy and eventually become more motivated.