Microservices

YouTube Talk link
Screen Shot 2017-12-05 at 11.41.32 PM

 

Components – A component is a unit which is independently replaceable and independently upgradeable. Like imagine a music system where you could change the amplifier without affecting the other system.
Like if a service needs to be moved to Java 8 but the other part of system is in Java 7, we don’t need to worry about those services.
Component generally comes in two part, using Library(3rd party or Own) and other services. I think each component can be a functional area.

Organized around bussiness capability – Like the business sees itself around the business goals and not technicals goals. So instead of having team of developer, UI, UX, DBA we have team for Order, Shipping, Catalog (image a e-commerce company like Amazon). Actually Amazon divided there team and each team is responsible for each of these from start till the end user experience.

Product not Projects

Smart Endpoint and Dumb Endpoint –  Instead of having a middleware where a lot of logic goes through, create smart end point which will do everything based on the input data. The routing or communication goes to the endpoint. Any business logic, routing everything is based on input. This is very much like the Internet where is very much like a dumb pipe, we just moves data and the actual process is done based on input.

Decentralized Data Management –  In the monolithic system each company had a single data source like Oracle or DB2. But in Microservices each service has it’s or can have it’s own specalized data store. Other service can’t talk to this data store directly and has to access it through the API. The Microservices Architecture pattern significantly impacts the relationship between the application and the database. Rather than sharing a single database schema with other services, each service has its own database schema. Having a database schema per service is essential if you want to benefit from microservices, because it ensures loose coupling.

Infrastructure  Automation – Each service has to be made independently deployable. Each service can have it’s own language and data store. So in an overall system there will be a number of individual components which we need to take care of. That’s why automation is necessary.

Design of Failure – If we have remote service, some will fail. So we need to be prepared. Netflix created Chaos Monkey to test how resilient there system is from failure by failing random nodes.

Evolution of Design

Difference b/w Monolith and Microservice

Screen Shot 2017-12-06 at 11.52.42 AM

 

Minimum basic needed for Microservices – 
1. Rapid provisioning of new machines
2. Basic Monitoring
3. Rapid Application Deployment Process
4. DevOps Culture – the operations and application group need to be working together

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies.
Each backend service exposes a REST API and most services consume APIs provided by other services.
Some REST APIs are exposed to the different clients but they don’t, however, have direct access to the backend services. Instead, communication is mediated by an intermediary known as an API Gateway. The API Gateway is responsible for tasks such as load balancing, caching, access control, API metering, and monitoring, and can be implemented effectively using NGINX.

Benefits

First, it tackles the problem of complexity. It decomposes what would otherwise be a monstrous monolithic application into a set of services. While the total amount of functionality is unchanged, the application has been broken up into manageable chunks or services. The Microservices Architecture pattern enforces a level of modularity that in practice is extremely difficult to achieve with a monolithic code base.

Second, this architecture enables each service to be developed independently by a team that is focused on that service. The developers are free to choose whatever technologies make sense, provided that the service honors the API contract.

Third, the Microservices Architecture pattern enables each microservice to be deployed independently. Developers never need to coordinate the deployment of changes that are local to their service.

Finally, the Microservices Architecture pattern enables each service to be scaled independently. You can deploy just the number of instances of each service that satisfy its capacity and availability constraints.

Drawbacks – 

Another major drawback of microservices is the complexity that arises from the fact that a microservices application is a distributed system. Developers need to choose and implement an inter‑process communication mechanism based on either messaging or RPC. Moreover, they must also write code to handle partial failure since the destination of a request might be slow or unavailable.

Another challenge with microservices is the partitioned database architecture. Business transactions that update multiple business entities are fairly common. These kinds of transactions are trivial to implement in a monolithic application because there is a single database. In a microservices‑based application, however, you need to update multiple databases owned by different services. Using distributed transactions is usually not an option, and not only because of the CAP theorem. They simply are not supported by many of today’s highly scalable NoSQL databases and messaging brokers. You end up having to use an eventual consistency based approach, which is more challenging for developers.

Testing a microservices application is also much more complex. In contrast, a similar test class for a service would need to launch that service and any services that it depends upon (or at least configure stubs for those services).

Another major challenge with the Microservices Architecture pattern is implementing changes that span multiple services. For example, let’s imagine that you are implementing a story that requires changes to services A, B, and C, where A depends upon B and B depends upon C. In a monolithic application you could simply change the corresponding modules, integrate the changes, and deploy them in one go. In contrast, in a Microservices Architecture pattern you need to carefully plan and coordinate the rollout of changes to each of the services. For example, you would need to update service C, followed by service B, and then finally service A. Fortunately, most changes typically impact only one service and multi‑service changes that require coordination are relatively rare.

Deploying a microservices‑based application is also much more complex.  successfully deploying a microservices application requires greater control of deployment methods by developers, and a high level of automation.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s