This is part four of the ever-expanding “Microservices and PaaS” blog series covering the rapidly evolving use of microservices in modern cloud software projects. Parts one and two introduced microservices concepts and discussed patterns and practices being spearheaded by microservices pioneers, notably Netflix, who were represented at a recent microservices meetup that was the genesis of this series.
Part three presented a list of challenges and pitfalls that adopters of microservices face. This list is formidable and somewhat daunting; pointing out the significant changes in mindset, organizational structure, and overall development practices needing to take place prior to plunging into microservices.
Fortunately, tooling and other supporting technologies are evolving almost as fast as the microservices practices are themselves. Platform-as-a-Service (PaaS) is at the forefront of this evolution and is now considered by many, for good reason, to be an essential component in the microservices toolset.
What follows, is a summary of a number of features provided by PaaS offerings that greatly simplify microservices development.
1. Polyglot Languages, Frameworks, and Persistence Layers
One significant benefit of microservices is that they don’t tie a team or an organization to a single development language or framework. Each service can be built using the language and framework suitable for the task, for the data, or for the team.
But each language stack must be downloaded, installed, configured, and provisioned separately. Requiring each developer or team to manually do this introduces considerable complexity and disrupts the overall development flow.
PaaS completely eliminates any manual steps needed to provision the development stack, whether Java on Spring, Ruby on Rails, or Python on Django.
These, and more, are instantly available when the microservice is deployed.
Similarly, microservices should use the persistence layer that makes sense for the job. Relational (MySQL), NoSQL (MongoDB), and caching (Redis) databases each have their own advantages, and a PaaS allows each to be instantly provisioned and wired to the microservice without requiring human intervention.
2. Consistent Testing Environments
Testing microservices is tricky, and practices to do so effectively are just now emerging. Regardless of the current state of testing, it’s safe to say that if there are inconsistencies between the environments where microservices are developed, tested, and deployed to production, chaos will ensue. It is crucial that each of these environments is identical. Subtle differences will result in inconsistent test results and will wreak havoc.
A PaaS provides a predictable and consistent environment in every place a microservice is deployed, such as development, staging, QA, and production. Furthermore, a microcloud such as one provided by Stackato, where the full cloud stack runs on a laptop or desktop, extends this homogeneity making it available to all developers and team members at all times.
As I’ve discussed earlier, dealing with logs in complex cloud applications is a pain. This is particularly true in microservices-based applications where each microservice instance generates its own logs.
PaaS goes a long way to reduce this pain by providing automated log aggregation mechanisms where multiple logs from multiple microservice instances can be aggregated automatically and redirected to any number of log aggregation services. The PaaS takes care of making sure logging “just works” and ensures that all logs from all applications can be easily directed to a centralized destination like Loggly or Splunk, or just as easily directed to a home-grown PaaS-hosted log application.
Like logging, monitoring is essential to the successful operation of a microservices-based application. But the days of hand-rolling monitoring solutions are over. With short-lived microservice instances rapidly starting, stopping, and moving around the network, it’s paramount that any monitoring solution be completely automated, with no human intervention required.
A PaaS will typically offer built-in monitoring to track common metrics, such as CPU load or memory use. In addition to providing these capabilities, Stackato also allows simple integration with specialized external monitoring tools and services such as Nagios and New Relic, and exposes the ability to manage and control the deployed microservices in response to monitoring events via its easily automatable REST interface.
Cloud applications must scale to accommodate variable usage loads. A microservices architecture allows separation of components so that the individual microservices that are causing a bottleneck can be scaled separately without having to scale out the entire application. This is a powerful approach, but scaling out multiple microservices is more complex than scaling out a single application instance.
Autoscaling is another area where PaaS shines. A specific microservice can be scaled automatically in response to metrics provided by internal or external instrumentation, responding to load events as they occur, without human intervention. The complexities of autoscaling, and the burden of dealing with these complexities, disappear when using a PaaS.
6. Service Discovery
Patterns for service discovery, naming, and routing to microservices are at their infancy. PaaS offerings like Stackato provide basic building blocks for accomplishing this, such as allowing service locations (URIs) and credentials to be injected into the application environment, as well as providing a means to publish and access these externally.
7. Instant Rollback and Versioning
As discussed in Part I of this blog series, the use of Immutable Service Patterns, where multiple service versions are deployed side by side, is a useful technique to enable continuous deployment and delivery of microservices in a way that allows new features to be rolled out safely.
A related practice is to use the built-in versioning and rollback mechanisms provided with a PaaS, where after deploying a new service version, it can be instantly rolled back to any previous version if a problem arises. For example, Stackato will keep track of every version of a microservice or application that gets deployed, and exposes both user interface and API to instantly rollback and roll-forward between these versions. The UI requires manual intervention, while the API allows this process to be easily automated in response to monitored events.
8. Availability and Failure Resilience
A failure in a monolithic application often brings the entire system to its knees. In contrast, a microservices system is composed of multiple independent loosely-coupled microservices. It can be designed so that the failure of one microservice will not significantly impact the rest of the system. It can continue to run in a degraded mode where the broken service (and perhaps the associated user interface) is disabled, but the rest of the application remains functional.
Obviously it’s preferable that all services remain operational at all times, and some services might be essential for the operation of the system. This requires a high-availability (HA) environment to guarantee that multiple microservice instances run across availability zones in order to survive the effects of catastrophic failure.
HA is an art and science in itself, but PaaS goes a long way to shield the complexity of HA from the developer. For example, Stackato allows the creation of multiple availability zones which can span racks or data centers, and can guarantee that one or more microservice instance is always running in each of these zones. Providing a common and simple availability platform goes a long way towards freeing the development team to focus on the application and not on the plumbing.
9. Get out of the Weeds
There are countless other areas in microservices where plumbing is required, and dealing with this plumbing hampers the overall development flow by adding complexity and cost. Examples include:
- routing network traffic to application instances
- load balancing
- multi-node cluster configuration and management
- interfacing with the infrastructure layer (IaaS)
- service naming and URI mapping
PaaS takes care of these plumbing details so the development team doesn’t need to get mired in the weeds.
10. On Demand / Self Service
A significant benefit of PaaS is its “self-service” nature, allowing the provisioning of resources on-demand without the need to submit a service ticket, or involve other humans in any way. This speeds development, streamlines the overall development flow, and allows free experimentation where developers can spin up clusters and services without being encumbered by process. This self-service capability is essential for a microservices-oriented development organization.
PaaS Fits Microservices
As Adrian Cockroft made abundently clear in his microservices presentation, PaaS is a crucial piece of the overall microservices story, for the reasons listed above and others. PaaS not only standardizes environments and significantly reduces complexity, but it also provides a foundation for the major organizational changes required to move to a microservices approach.
Very few development organizations have the means and resources that Netflix had at their disposal to push through a company-wide initiative to overhaul their entire software architecture, organization, and mindset to a microservices approach. As Donnie Berkholz pointed out in his fireside chat with Bernard Golden, changing the org-chart is itself a huge undertaking, and this won’t happen until the tooling is in place to lower the barriers for devops.
The tooling Donnie is referring to is evolving as PaaS, which provides a powerful and self-service means for targeted teams to successfully deliver microservices. Stackato, the world-class enterprise PaaS from ActiveState, is a prime example of a PaaS offering that streamlines microservices development.
If you would like to learn more about microservices and PaaS, watch the recording of the webinar Get Started with Microservices and PaaS
Feature image via Flickr Creative Commons.
John Wetherill is ActiveState’s Developer Evangelist. Originally from Canada, John has spent much of his career designing and building software at a handful of startups, at Sun Microsystems, NeXT Inc., and more recently in the smart grid and energy space. His biggest passion is for developer tools, or more generally any tool, language, process, or system that improves developer productivity and quality of life. Without question, Stackato is one such tool and the reason why he is here. No stranger to technology evangelism, John spent several years in the late 1990’s on Sun’s Technology Evangelism Team spreading the Java Gospel across the globe and focusing on the prolific number of Java technologies. John is now returning to his roots, as a technology evangelist working for a Canadian company, albeit remotely from Santa Cruz. Follow John on Twitter for the latest about microservices, PaaS and the movements that ActiveState participates in and closely follows.