Microservices has been making waves among forward-thinking application development organizations since the term was first coined in 2011. A few short years later, microservices is on the verge of going mainstream, as, according to a recent survey from Nginx, 36 percent of enterprises surveyed are currently using microservices, with another 26 percent in the research phase. But what exactly is microservices architecture, and is it right for your organization’s culture, skills, and needs?
Here we take a look at seven reasons you should consider microservices for your next application development project — and five hurdles you’ll have to clear to be successful.
The case for microservices
A variant of service-oriented architecture (SOA), microservices is an architectural style in which applications are decomposed into loosely coupled services. With fine-grained services and lightweight protocols, microservices offers increased modularity, making applications easier to develop, test, deploy, and, more importantly, change and maintain.
[ Find out why adopting microservices is easy in theory, but not in reality. | Beware the 12 ‘best practices’ IT should avoid at all costs. | Get the latest insights by signing up for our CIO daily newsletter. ]
No doubt your organization is still strapped with applications developed in the monolithic era, when centralized, multi-tier architectures were used to create entire applications on a single codebase. That client-service model was an excellent choice when desktops ruled IT. But with the rise of mobile devices and the cloud, back-end data must always be available for a wide range of devices, and that monolithic architecture isn’t going to make it easy on you , as whenever a change is made, the entire application has to be updated, opening up the possibility of new bugs every time you try to add a feature or adjust to a new context. Worse, with everything tied to a single codebase, you can’t scale a specific function or service; you have to scale up the entire application, leading to vastly higher costs.
With microservices, your code is broken into independent services that run as separate processes. Output from one service is used as an input to another in an orchestration of independent, communicating services. Microservices is especially useful for businesses that do not have a pre-set idea of the array of devices its applications will support. By being device- and platform-agnostic, microservices enables businesses to develop applications that provide consistent user experiences across a range of platforms, spanning the web, mobile, IoT, wearables and fitness tracker environments. Netflix, PayPal, Amazon, eBay, and Twitter are just a few enterprises currently using microservices.
Walmart Canada, for example, refactored its software architecture to microservices in 2012. The company, which had not been able to handle the 6 million page views per minute it was getting at the time, realized instant results with a significant increase in its conversion rate overnight. Downtime was minimized, too, and the company was able to replace expensive commodity hardware with cheaper virtual x86 servers, resulting in an overall cost savings between 20 and 50 percent.
Even if your organization is not the size of a Walmart or Amazon, microservices can still provide great value. Here are some of the benefits your organization will enjoy in switching to microservices.
With microservices, your entire application is decentralized and decoupled into services that act as separate entities. Unlike the monolithic architecture wherein a failure in the code affects more than one service or function, there is minimal impact of a failure using microservices. Even when several systems are brought down for maintenance, your users won’t notice it.
Scalability is the key aspect of microservices. Because each service is a separate component, you can scale up a single function or service without having to scale the entire application. Business-critical services can be deployed on multiple servers for increased availability and performance without impacting the performance of other services.
With microservices, you don’t have to get tied up with a single vendor. Instead, you have the flexibility to use the right tool for the right task. Each service can use its own language, framework, or ancillary services while still being able to communicate easily with the other services in your application.
Faster time to market
Because microservices works with loosely coupled services, you don’t need to rewrite your entire codebase to add or modify a feature. You make changes only to a specific service. By developing applications in smaller increments that are independently testable and deployable, you can get your application and services to market quicker.
Easier debugging and maintenance
Microservices also makes it easy to debug and test applications. With smaller modules going through a continuous delivery and testing process, your ability to deliver error-free applications is vastly improved.
Improved ROI with reduced TCO
Microservices also allows you to optimize resources. With microservices, multiple teams work on independent services, enabling you to deploy more quickly — and pivot more easily when you need to. Development time is reduced, and your teams’ code will be more reusable. By decoupling services, you won’t have to operate on expensive machines. Basic x86 machines will do. The increased efficiency of microservices not only reduces infrastructure costs, it also minimizes downtime.
Unlike monolithic applications, in which dedicated teams work on discrete functions such as UI, database, server-side logic, and technological layers, microservices uses cross-functional teams to handle the entire life cycle of an application using a continuous delivery model. When developers, operations, and testing teams work simultaneously on a single service, testing and debugging becomes easy and instant. With this approach of incremental development, code is continuously developed, tested and deployed, and you can use code from existing libraries instead of reinventing the wheel.
Microservices is not for every business
Businesses that have embraced microservices have realized significant benefits, and organizations that ignore this fact may be left behind. But while microservices looks promising, not every business can capitalize on the architecture. Make sure your business is capable enough to manage it. Here are some organizational caveats.
You’ll need to be equipped for rapid provisioning and app deployment
With incremental development and continuous delivery, microservices keeps your organization on its toes. Staff should be able instantly to provision resources to keep up with the pace required to make the most of microservices. If it takes days or months to provision a server, you’ll run into serious trouble. Similarly, you should be able quickly to deploy new services or applications.
Robust monitoring is a must
Because each service relies on its own language, platform, and APIs, and you will be orchestrating multiple teams working simultaneously on different entities of your microservices project, you need robust monitoring to effectively monitor and manage the entire infrastructure, because if you don’t know when a service fails or a machine goes down, it may be impossible to track down issues when they arise.
You must embrace devops culture
To work in cross-functional teams, your business should incorporate devops practices and culture. In a traditional setting, developers are focused on features and functionalities, and the operations team is on the hook for production challenges. In devops, everyone is responsible for service provisioning — and failure.
Testing can be complex
With microservices, testing isn’t straightforward. Each service has its own dependencies, some direct, others transitive. As features are added, new dependencies will pop up. Keeping tabs on all this quickly becomes impractical. Plus, as your number of services increases, so too does the complexity. Whether it’s database errors, network latency, caching issues, or service unavailability, your microservices architecture better be able to handle a reasonable level of faults. So, resiliency testing and fault injection are a must.
You need to design with failure in mind
Designing for failure is essential. You should be prepared to handle multiple failure issues, such as system downtime, slow service and unexpected responses. Here, load balancing is important, but having a plan B is another important option. When a failure arises, the troubled service should still run in a degraded functionality without crashing the entire system.