As we look forward to 2017, we see signs of continued rapid innovation in the digital landscape. We expect microservices to be a big player in the field.
In the past four years, interest in microservices have skyrocketed, as demonstrated above by Google searches on the topic.
However, what are microservices? Why are the useful? What are their upsides and downsides? How will they impact any monitoring you might do on your website? This blog post attempts to answer these questions and show how they might affect you as you make plans for the upcoming year.
What are Microservices?
Microservices are small, independent processes that can interact with other small processes that for a complete application when implemented and utilized together. Rather than forcing you to deploy a complex application, using microservices allows you to be flexible and focus on each process to do. Generally speaking, do one thing and to do it well.
With the popularity of Agile methods, DevOps as its own (prominent) entity, and continuous integration/deployment in today’s software engineering world, it is now possible and increasingly common to build large-scale systems that are truly modular. Complex software that was once shipped as a single, large entity is now being broken down into its constituent parts for design, implementation, and maintenance. Ideally, each microservice is created by a full-stack team to minimize communication mismatches. Language-agnostic APIs facilitate communication between the microservices and therefore do not require continuous user intervention.
Why are Microservices Useful?
Using microservices offers a number of benefits. First, microservices address the issue of complexity by decomposing what would have been a large, monolithic application into a set of smaller processes. Once all of the microservices are implemented, the end functionality is identical to that of the monolithic application, despite the fact that each smaller service has a well-defined boundary in the form of an API. This also results in products that are faster to develop and easier to maintain.
Second, microservices allow each team of developers to focus exclusively on implementing one function. In addition to increased productivity due to the specificity of the code, each team can choose the language and technology stack that is best for the task, provided that, in the end, the service honors the API contract. To be sure, many companies will want to place limits on the languages and technologies used, but developers are not locked into specific tools as time goes on.
Third, each microservice can be deployed independently. This reduces the need for teams to coordinate with each other with regards to deployments and enables continuous deployment. Additionally, this independence means that, in the event there is an issue with a given service (memory leaks, database connection issues, and so on), only one service is affected. All other functions remain available, which limits the number of people affected by a given failure.
Are There Downsides to Microservices?
While there are solid benefits to using microservices, there are certainly drawbacks that you need to consider when decided whether to implement this type of architecture.
One major drawback is the complexity that arises from the fact that an application composed of microservices is a distributed system. As each development team implements their service, it’s important to ensure interprocess communication mechanisms are accounted for. In addition, developers must ensure their code can handle a partial failure anywhere within the program architecture since the destination of a request might be slow or even unavailable.
Another challenge involves the partitioned databases utilized in microservices architecture. Transactions that update multiple entities within a database are quite common. In a traditional application, this is no problem since there is only one database to be considered. With microservices, however, different services own different databases. This ensures the appropriate updates are made at the appropriate time can be challenging for developers.
Testing can be challenging as well. Each individual service can easily be tested by the team that owns it. However, testing the entire application and its behavior in a variety of situations can be difficult.
Lastly, deploying a microservices-based application is more complex than deploying a tradition monolithic application. Such applications typically are composed of a large number of services, and each service requires multiple runtime instances. The number of moving parts that need to be configured, deployed, and monitored quickly multiplies. Generally, success requires developers to have greater control over the deployment methods used and high levels of automation.
How Does Using Microservices Impact Your Site’s Monitoring?
The independent nature of microservices make performance monitoring challenging. In addition to there being more systems to monitor and track, it’s often difficult to track down the root cause of an issue in the event of a multi-process failure. Additionally, you might have deployed your application using an off-the-shelf platform-as-a-service (PaaS) to remove some of the moving parts you have to be responsible for. The downside to this is limited control over and insight into the infrastructure that the application relies on. Given these issues, it’s important to pick the right tool to monitor your application. However, what makes a given tool the right one?
An application composed of microservices is inherently complex, and a natural consequence of this is the exponential increase in the number of warning or error messages. As such, you should be thinking of monitoring from the very get go. Your tool should, for starters, monitor your application as if it were the user (regardless of whether the application is consumed by an actual person or another piece of software). One of your primary end goals is to create the best possible experience for your user. To do this, you must monitor and gather information from this perspective.
Focus on Your System
Furthermore, you might consider focusing your monitoring on your system as a whole. Because there are so many things that can be watched and only a finite amount of resources, you should concentrate your attention on the overall system and its functionality from the end user’s point of view. This also results in fewer alerts (which should be clear and contain sufficient information to pinpoint the specific location of an issue) that are provided and acted upon by your team.
Finally, your monitoring tool should be able to handle any infrastructure option you might choose to support your deployment. Regardless of whether you choose to use only managed services, only vendor-provided services, or some mix in between, you should be able to configure a clean system that alerts you when necessary and provides only the information necessary to correct the issue (and no more, since the sheer amount of information provided by a typical application is so high that most of it ends up being processed as noise, rather than signal).
Rigor’s multi-step API Check records and confirms your performance data. The API Check also sends alerts to the assigned user as soon as a check fails.
With the increased popularity of microservices comes the need for monitoring tools that can handle the complexity such an architecture choice poses. Be sure that you have what you need to handle the changes for the upcoming year!
For customized information on how Rigor can help your company with its monitoring and optimization needs,