Microservice Architecture (a.k.a. \u201cMicroservices\u201d) is a method of developing software focused on building single-function modules. The term was <a href="https:\/\/en.wikipedia.org\/wiki\/Microservices#Introduction">coined in 2011<\/a> and the microservice approach quickly gained steam near the end of 2013:\r\n\r\n<a href="https:\/\/trends.google.com\/trends\/explore?date=2011-06-12%202019-07-12&geo=US&q=microservices"><img class="lazy aligncenter wp-image-20384 size-large" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/07\/microservices-popularity-time-1110x394.png" alt="Growth in microservices popularity" width="730" height="259" \/><\/a>\r\n\r\nThe advancement of microservices was driven, in part, by tech giants like Netflix, Amazon, Twitter, Google, and Uber evangelizing its benefits.\r\n<h2>What\u2019s all the microservice buzz about?<\/h2>\r\nWhy is anyone interested in microservices? To answer that question we need to briefly explore the evolution of software architecture.\r\n<h3>Monoliths<\/h3>\r\nNot long ago, most software was \u201cmonolithic.\u201d A monolithic design means the user interface and the data access code are combined into a single, self-contained program.\r\n\r\nMonolithic software design comes with some downsides. Most notably, because of the self-contained, interdependent nature of monoliths, a failure anywhere in a program can cause the whole application to come crashing down. And, there are other issues:\r\n<ul>\r\n \t<li><strong>Reduced agility.<\/strong> The application\u2019s codebase is released all at once. Developers need to code and deploy the entire stack. Rebuilding the whole application takes time and slows down the pace at which new features can be delivered.<\/li>\r\n \t<li><strong>Complexity.<\/strong> Large applications become harder to understand and work with. There are side effects of changes that might not be obvious due to easy-to-overlook dependencies leading to \u201cmysteries and magic\u201d that can be difficult to untangle.<\/li>\r\n \t<li><strong>Less scalability.<\/strong> Scaling becomes a matter of adding new instances to run the entire codebase rather than adding instances to scale individual pieces of the app that might be used more than others. Unequal usage of that application can lead to some resources being wasted and other resources straining the server.<\/li>\r\n<\/ul>\r\n<h3>Service-Oriented Architecture<\/h3>\r\nTo overcome these problems, a <a href="https:\/\/en.wikipedia.org\/wiki\/Service-oriented_architecture">Service Oriented Architecture<\/a> (SOA) was introduced and became popular in the early and mid-2000s. The SOA views an application as a collection of services running in parallel and connected by application programming interfaces (APIs). Each service is self-contained and represents a specific business activity with a desired outcome.\r\n\r\nThis approach helps solve many of the downsides inherent to monolithic software designs:\r\n<ul>\r\n \t<li><strong>Easy maintenance.<\/strong> Distinct services can be updated without affecting other services.<\/li>\r\n \t<li><strong>Platform independence.<\/strong> You can create an application by combining services that use different solutions.<\/li>\r\n \t<li><strong>Improved <a href="https:\/\/pagely.com\/blog\/wordpress-data-reliability\/">reliability<\/a>.<\/strong> It is easier to locate the problem and debug a small service than it is with a monolith\u00a0<span style="font-weight: 400;">and a single service going down usually won\u2019t take down the entire application.\u00a0<\/span><\/li>\r\n \t<li><strong>Scalability.<\/strong> Individual services can scale by adding server resources as demand increases.<\/li>\r\n<\/ul>\r\nThe Microservice Architecture (MSA) is a variant of SOA. In fact, some people argue that MSA and SOA are not really different things at all, so the term \u201cmicroservices\u201d is superfluous. Nevertheless, the term seems to be here to stay.\r\n<h2>What are microservices?<\/h2>\r\n<a href="https:\/\/www.quora.com\/What-are-the-alternatives-to-microservices\/answer\/Jerry-Andrews?ch=10&share=47420578&srid=QhZeq">According to Jerry Andrews<\/a>, when people talk about MSA they\u2019re generally referring to software design that includes these characteristics:\r\n<ul>\r\n \t<li>Services typically rely on other services to accomplish their goals<\/li>\r\n \t<li>Services are often <a href="https:\/\/cloud.google.com\/containers\/">containerized<\/a> using a container tool such as <a href="https:\/\/www.docker.com\/">Docker<\/a> but they could also run in a virtual machine (VM)<\/li>\r\n \t<li>Asynchronous communication is handled via messaging or job queues and synchronous communication is handled via HTTP with JSON messages<\/li>\r\n \t<li>Instance management automation<\/li>\r\n \t<li>Auto-scaling components<\/li>\r\n<\/ul>\r\nThere is some debate on the exact definition and some would argue with aspects of the defining characteristics repeated here.\r\n\r\nSOA and MSA are also differentiated by how granular services are:\r\n\r\n<a href="https:\/\/dzone.com\/articles\/microservices-vs-soa-whats-the-difference"><img class="lazy aligncenter wp-image-20386 size-large" src="https:\/\/pagely.com\/wp-content\/uploads\/2019\/07\/monolith-soa-microservices-granularity-1110x708.png" alt="Service Granulariity of Monoliths vs SOA vs Microservicess" width="730" height="466" \/><\/a>\r\n<p style="text-align: center;"><em>Source:<\/em> <a href="https:\/\/dzone.com\/articles\/microservices-vs-soa-whats-the-difference">Dzone<\/a><\/p>\r\nThere are also differences in how individual services are conceptualized. SOAs view services through distinct lenses:\r\n<ul>\r\n \t<li>Business services<\/li>\r\n \t<li>Enterprise services<\/li>\r\n \t<li>Application services<\/li>\r\n \t<li>Infrastructure services<\/li>\r\n<\/ul>\r\nIn contrast, MSA views services purely as functional (without viewing them through the separate lenses SOA does). Microservices might be created for discrete functional services like:\r\n<ul>\r\n \t<li>Authentication<\/li>\r\n \t<li>Email sending<\/li>\r\n \t<li>Account management<\/li>\r\n \t<li>Account creation<\/li>\r\n \t<li>Billing<\/li>\r\n \t<li>Messaging<\/li>\r\n<\/ul>\r\n<h3>Microservice architecture versus APIs<\/h3>\r\nWhen learning about microservice architecture there is often some confusion on how it's different than an API endpoint. The clearest way to express the difference between these two terms is to point out that an API is about <em>communication<\/em> and a microservice is about how the software is <em>organized<\/em>.\r\n\r\nAn API allows an app's data to be accessed or instructs the app to perform a function. This communication can happen either internally (in the case of a private API) or externally (in the case of a public API). These functions could be:\r\n<ul>\r\n \t<li>Making changes to data<\/li>\r\n \t<li>Pull data out of one app so it can be brought into another<\/li>\r\n \t<li>Telling the app to create a new user<\/li>\r\n \t<li>Triggering the app to send out an email<\/li>\r\n<\/ul>\r\nA microservice may leverage APIs to allow different services to interact but the term refers specifically to how an application is divided up.\r\n\r\nIf the difference between an API and MSA is still unclear, here's a great video from IBM that explores the differences in more depth:\r\n\r\n<iframe src="https:\/\/www.youtube.com\/embed\/WFtmCaqIjkA" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"><\/iframe>\r\n<h2>Benefits of Microservices<\/h2>\r\nThe self-contained nature of individual microservices introduces <a href="https:\/\/skelia.com\/articles\/5-major-benefits-microservice-architecture\/">a variety of benefits<\/a>:\r\n<ul>\r\n \t<li><strong>Simplicity.<\/strong> Microservice architectures are usually more simple so they can be easier to build and maintain.<\/li>\r\n \t<li><strong>Autonomous cross-functional teams.<\/strong> Technical decisions can be made faster and by smaller groups.<\/li>\r\n \t<li><strong>Flexibility in technology.<\/strong> Like the SOA approach, microservices allow a blend of solutions to work together.<\/li>\r\n \t<li><strong>Flexibility in <a href="https:\/\/pagely.com\/kb\/en\/what-is-horizontal-scaling\/">scalability<\/a>.<\/strong> Microservices can scale independently so additional resources can be added exactly where they\u2019re necessary.<\/li>\r\n \t<li><strong>Code can be re-used.<\/strong> For example, here at <a href="https:\/\/pagely.com">Pagely<\/a> we were able to use some Pagely-made microservices to power our new serverless hosting solution, <a href="https:\/\/northstack.com">NorthStack<\/a>.<\/li>\r\n<\/ul>\r\n<p style="text-align: left; padding-left: 40px;"><em>Source:<\/em> <a href="https:\/\/skelia.com\/articles\/5-major-benefits-microservice-architecture\/">Skelia<\/a><\/p>\r\n\r\n<h2>The downsides of microservices<\/h2>\r\nWhile many companies are refactoring their monoliths in favor of a microservices approach, microservices aren\u2019t always the right answer. It\u2019s not the one true perfect way to design an application that everyone should always use. In many cases, the upsides of MSA outweigh the downsides, but sometimes not because:\r\n<ul>\r\n \t<li><strong>Microservices can introduce complexity.<\/strong> A monolith\u2019s complexity comes from how challenging it can be to understand how different code interacts, MSA\u2019s complexity comes from having more and more of the code split out into individual services. Five or six services aren\u2019t difficult to manage, but twenty, thirty, or more can be!<\/li>\r\n \t<li><strong>Microservices require changes to culture and process.<\/strong> Companies that adopt microservices will also need to adopt an agile coding approach and, often, create a DevOps team.<\/li>\r\n \t<li><strong>Microservices can be costly.<\/strong> Network calls made by APIs aren\u2019t free and add up. In addition, the labor costs of breaking up a monolith can create an otherwise unnecessary expense.<\/li>\r\n \t<li><strong>Microservices may introduce security issues.<\/strong> Each inter-network communication path creates a new security risk that needs to be addressed and monitored.<\/li>\r\n<\/ul>\r\n<p style="padding-left: 40px;"><em>Source:<\/em> <a href="https:\/\/www.tiempodev.com\/blog\/disadvantages-of-a-microservices-architecture\/">Tiempo Development<\/a><\/p>\r\n\r\n<h2>Moving from monolith to microservices<\/h2>\r\nMany applications begin their lives as monoliths, but as they mature bottlenecks that should be split out into microservices become apparent. This refactoring process is known as \u201cbreaking up the monolith.\u201d The two architecture approaches are not an \u201ceither-or\u201d thing or a \u201cright or wrong\u201d thing\u2014 many popular apps are a monolith-microservices hybrid.\r\n<h2>Starting from scratch: Monolithic versus Microservice architecture<\/h2>\r\nWhile microservices offer distinct advantages over monoliths, building software from scratch as a monolith and then moving toward a microservice approach may sometimes make more sense:\r\n<ul>\r\n \t<li>Developing an application as microservices will usually be slower (initially) than taking a monolith approach<\/li>\r\n \t<li>As the monolithic software matures and the big picture becomes more clear, the functions that should be split out into microservices will be more obvious.<\/li>\r\n \t<li>A well-designed monolith can easily be broken out into microservices later.<\/li>\r\n<\/ul>\r\nIf development time is a non-issue, taking a microservices approach from the beginning avoids the effort and expense of later refactoring. You could weigh the pros and cons of absorbing the time costs of starting with microservices versus delaying those costs and beginning with a monolith. The right answer will depend on the priorities of the company and its project.