Micro-services are the first post DevOps revolution architectural design Style, the first to fully encompass the engineering practices of continuous delivery. It’s also an example of evolutionary architecture, which supports an incremental non-breaking change as the first principle along several dimensions at the structural level of the application.
Nevertheless, it’s just one of the group of architectures that supports certain evolutionary behavior. This article investigates some characteristics and principles of the family of architectural design style. Micro-services are the hot new thing in commercial application development. The term micro-service has replaced Agile, DevOps, and Restful as a hot new phrase and is talk of the town and no way a passing whim. In fact, they’re the evolution of any of those Past Concepts and approach which has started to show the promise of cutting through a series of long standing issues in application development.
With thousands of customers-to-be every day and a direct major business impact, it’s just not necessary to be reliable as well as always up and running, but additionally Quite flexible and fast, allowing product improvements, error corrections and multi variant tests to be rolled out in near real time. Helping to achieve goals of continuous live installation infrastructure, the near real time monitoring as well as alarming setup and more importantly the constant evolving and stateless micro services. To understand this development, we have to take a step backward in time to examine what micro services are, what they replaced, and why they became necessary.
Let us start in the early 80’s with the introduction of the first important systems distribution technologies: Remote Procedure Calls (RPC) was the concept behind Sun Micro-systems first ONC RPC and also the main idea behind DCE and CORBA. In each of that technology, the basic idea was to make remote calls transparent to developers. The promise was that if programmers did not have to care whether the procedure calls or methods they were invoking were local or remote, then they could build larger machine crossing systems that could avoid the processing and memory scalability problems which affected systems of the time.
Now, at this point there is a need to mention the characteristics of Evolutionary Architectures:
Modularity and Coupling: The capability to separate components at clearly defined boundaries has obvious benefits if a developer wants to make a non-breaking change.
Organized around business capabilities: Service-based architectures differ from conventional SOA. SOA is strictly shared across technical levels, while service based architectures tend towards the microservice’s inspired domain partitioning.
Experimentation: This enables your company to spend less time speculating about story backlogs and instead participate in hypothesis driven development. As processors enhanced and local address spaces became bigger, this issue became less significant.
As processors improved and local address areas became larger, this problem has become less attention grabbing. The idea of reaching better isolation at the same time as at the same time making it feasible to extra easily debug micro services is at the core of numerous DevOps patterns.