{"id":49136,"date":"2017-06-05T13:54:23","date_gmt":"2017-06-05T08:24:23","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=49136"},"modified":"2017-06-05T16:47:51","modified_gmt":"2017-06-05T11:17:51","slug":"an-overview-of-microservice-architecture-part-i","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/an-overview-of-microservice-architecture-part-i\/","title":{"rendered":"An Overview of Microservice Architecture – Part I"},"content":{"rendered":"

Companies want to bid farewell to legacy architecture and digitize their business models, products and infrastructure. While some advanced companies are leveraging two-speed IT, DevOps<\/a> and Cloud, some others are still trying to figure out a way to build disruptive web and mobile products faster.<\/p>\n

Moreover, growing consumer demands have increased the need to build large scale and complex applications meeting the requirements of end users. Traditional product development teams used to work on a single monolithic deployment artifact. Monolithic architectural style puts all its functionality into a single process and scales by replicating the monolith on multiple servers.<\/span><\/p>\n

However, it was challenging to continuously manage one large monolith. Agile software teams<\/a> weren’t able to leverage Agile principles in a real way. They found the monolith too complex to understand and debug. They were also challenged to implement new features, updates and releases. <\/span><\/p>\n

Moreover, monolithic architecture also impacted startup time of applications. In one of the <\/span>surveys<\/span><\/a>, developers reported startup times as long as 12 minutes. Apple suggests to aim for a total app launch time of under 400ms and you must do it in less than 20 seconds or the system will kill your app.<\/span><\/p>\n

Continuous deployment was another pain point with most monolithic architecture. Development teams need to push changes to production multiple times a day and with so many releases being shipped, it is extremely difficult to redeploy entire monolith again and again just to update a small part of it. Moreover, as the impact of the change is difficult to understand, it would require an extensive testing effort every time there is a need to update or deploy. <\/span><\/p>\n

Furthermore, monolithic applications are less reliable as modules run within the same process. The breakdown in any of the modules will impact entire process and ultimately hamper the user experience. For development teams, a larger challenge was to identify the bugs from various identical instances and make the application available at all times. <\/span><\/p>\n

With monolithic applications, it is also very difficult to adopt new framework and language. As it is difficult to change and rewrite code, it is not possible to introduce a new framework to improve specific aspects of the application. Monolithic applications hence present a huge barrier to adopting new technologies.<\/span><\/p>\n

Clearly, monolithic applications are a tough nut to crack. They are difficult to understand and scale with time. <\/span><\/p>\n

Microservice Architecture – A shift to resolve the complexity <\/b><\/p>\n

What are microservices?<\/b><\/p>\n

\u201cA loosely coupled service oriented architecture with bounded contexts to make sure you break your problem into the right chunks\u201d \u00a0– Adrian Cockcroft<\/span><\/p>\n

\u201cAn approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms\u201d \u2013 Martin Fowler<\/span><\/p>\n

With the focus on developing applications faster and cut down on the development costs, microservices are quickly gaining traction among software development teams. Agile teams find this architectural style a key enabler for improving the product delivery process.<\/span><\/p>\n

Microservice architecture divides the single application into a small set of services, each running on its own but communicating with each other through APIs.<\/span><\/p>\n

A service implements some of the features or functionality such as customer management, partner management and so on. Each of these services\u00a0is mini-applications having their own hexagonal architecture. Such an architecture comprises of business logic. Out of these services, there will be some that would expose an API that\u2019s consumed by some other microservices or by app\u2019s clients whereas some others might just implement a web UI. At runtime, each instance is often a cloud VM or a Docker container.<\/span><\/p>\n

Additionally, microservice architecture doesn’t just put each element of functionality into a separate service but also scales by distributing these set of small services across various servers and replicating them as and when needed.<\/span><\/p>\n

Organizations such as Netflix and Amazon have started leveraging this new style of developing applications for some time now. <\/span><\/p>\n

The concept of microservices is considered as a variant of the existing service-oriented architecture (SOA) architectural style that structures an application as a group of loosely coupled services. Software development teams that are interested in leveraging\u00a0<\/span>microservice architecture<\/span> should ensure that the services are fine-grained and the protocols are lightweight.<\/span><\/p>\n

Some of the design characteristics of <\/span>microservice architecture<\/span> include:<\/span><\/p>\n