Contact Info
London Office :
Denizli Office :
Pamukkale Üniversitesi Teknoloji Geliştirme Merkezi B Blok Oda:Z17, 20070 Denizli
info@cloudnesil.com
+88 (0) 101 0000 000
Certified Kubernetes Administrator Certified Developer on Apache Cassandra

Cloud Nesil

MICROSERVICES ARCHITECTURE

 DEFINITIONS
‣ 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
 
CHALLENGES WITH MONOLITHIC SOFTWARE
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
 
MONOLITHIC VS. MICROSERVICES
 
 
MONOLITHIC VS. MICROSERVICES
 
 
WHY SHOULD WE USE?
‣ 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
‣ Legacy systems can be supplemented with microservices without the need to carry around all the ballast that has accumulated in the legacy system. Therefore, microservices are good to use when dealing with legacy systems.
‣ Microservices can be scaled independently
‣ Each microservice can be implemented in a different programming language and with a different technology
‣ Smaller Projects
‣ Smaller Teams
‣ Clear ownership and accountability
 
OR SHOULDN’T WE USE 🙂
‣ 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
 
BASICS
‣ 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
‣ 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
‣ 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
‣ UI tests check the application via the user interface
‣ In principle, they only have to test whether the user interface works correctly
 
MANUAL TESTS
‣ Check certain aspects like security, performance, or features that have caused quality problems
 
BASICS
‣ 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)
 
 
SPIN UP THE FULL SYSTEM LOCALLY
‣ 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
 
 
 
SPIN UP THE FULL SYSTEM IN THE CLOUD
‣ 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
‣ 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.
 
 
MAKE LOCAL CODE FOR SINGLE SERVICE AVAILABLE IN REMOTE CLUSTER
‣ 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
 

Post a Comment

Retype the CAPTCHA code from the image
Change the CAPTCHA codeSpeak the CAPTCHA code