‣ 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.

– Martin Fowler

‣ Small autonomous services that work together, modeled around a business domain.

– Sam Newman, Thoughtworks Inc. (from building microservices book)

‣ Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities

– Chris Richardson – CloudFoundry

‣ Microservices is a variant of the SOA that structures an application as a collection of loosely coupled services. In a microservices architecture, services should be fine-grained and the protocols should be lightweight.

It also parallelizes development by enabling small autonomous teams to develop, deploy and scale services independently. Microservices-based architectures enable continuous delivery and deployment

– Wikipedia

1. Difficult to scale (Lack of agility)

2. Long build/test/release cycles (Lack of innovation)

3. Long time to add new features (Frustrated customers)

4. Too much software coupling

5. Large Codebase

6. Many Components, no clear ownership

 

 

 

 

‣ Rapid build/test/release cycles

‣ Strong modularization ensures that dependencies between microservices can not easily creep in

‣ Microservices can be easily replaced

‣ The strong modularization and the replaceability of microservices leads to a sustained speed of development the architecture remains stable, and micro services that cannot be maintained any longer can be replaced. Thus, the quality of the system remains high in the long run, so that the system stays maintainable

‣ Strong modularization ensures that dependencies between microservices can not easily creep in

‣ Microservices can be easily replaced

‣ The strong modularization and the replaceability of microservices leads to a sustained speed of development the architecture remains stable, and micro services that cannot be maintained any longer can be replaced. Thus,

the quality of the system remains high in the long run, so that the system stays maintainable

‣ Smaller Projects

‣ Smaller Teams

‣ Clear ownership and accountability

‣ There is no silver bullet in software design!

‣ Understanding of business domain

‣ Coordinating transactions across multiple services

‣ Complexity of testing/deploying/operating a distributed system

‣ Development environment setup

‣ Log monitoring

‣ Cultural transformation

‣ The division of a system into microservices has an impact on testing

‣ In a microservice-based system the entire system consisting of all microservices has to be tested

‣ This can be difficult when there are a large number of microservices

‣ Microservices provide technology freedom; nevertheless, there have to be certain standards, and tests can help to enforce the technical standards

 

‣ Unit tests examine the individual units that compose a system just as their name suggests

‣ They minimize the risk that an individual unit contain errors

‣ Unit tests are intended to check small units, such as individual methods or functions

‣ In order to achieve this, any dependencies that exist in the unit have to replaced so that only the unit under test is being exercised and not all its dependencies (Mock or Stub)

‣ Integration tests check the interplay of the components

‣ This is to minimize the risk that the integration of the components contain errors

‣ They do not use stubs or mocks

‣ The components can be tested as applications via the UI or via special test frameworks

‣ UI tests check the application via the user interface

‣ In principle, they only have to test whether the user interface works correctly

 

‣ Check certain aspects like security, performance, or features that have caused quality problems

‣ In particular, setting up a productive development environment for microservices can be considerably more complex than a traditional web application

‣ Your service might rely on other services that either you or your coworkers maintain

‣ External dependencies add complexity to creating and maintaining a development environment

‣ There are various approaches to setting up a development environment. (from 100% local to 100% remote)

‣ Using tools like Minikube or Docker Compose, you can spin up multiple services locally

‣ Pros:

– Fast, local development

‣ Cons:

– Need a way to set up and run all your services locally and keep

this setup in sync with how you run services in production

– Need to spin up the whole system locally, which will become

difficult once you have a large enough number of services and

resources

 

‣ You spin up a realistic cluster in the cloud, a staging/testing environment

‣ It might not have as many nodes as the production system since load will be much lower

‣ Pros:

– Very realistic

‣ Cons:

– Development is slower since you need to push code to cloud after every change in order to try it out

– Using tools like debuggers is more difficult since the code all runs remotely

– Getting log data for development is considerably more complex.

– Need to pay for additional cloud resources

 

‣ Spin Up All Business Logic Locally, Route Cloud Services to Laptop

‣ As with option 1, all services run locally. However, cloud resources are made available locally on your development machine via some sort of tunneling or proxying, e.g., a VPN

‣ Pros:

‣ Fast, local development

‣ Very realistic.

‣ Cons:

‣ You need a way to set up and run all your services locally and keep this setup in sync with how you run services in production

‣ Need to pay for additional cloud resources, and spinning up new cloud resources is slow.

‣ You spin up a realistic cluster in the cloud, a staging/testing environment, but your service runs locally and is proxied/VPNed into the remote cluster

‣ Pros:

– Fast, local development.

– Very realistic.

– Simple local setup

‣ Cons:

– Need to pay for additional cloud resources, and spinning up new cloud

resources is slow

– Configuring a proxy or VPN that works with your cluster can be complex

Conway’s Law

“Any organization that designs a system will inevitably

produce a design whose structure is a copy of the

organization’s communication structure”

 

Melvin E. Conway, 1967