PaaS vs. IaaS for Microservices Architectures: Top 6 Differences
Although monolithic architectures are prevalent today, they might not be the best fit for complex cloud-based systems—especially if you implement changes frequently. That’s where microservices enter the arena to overcome the challenges by splitting monoliths into multiple independent services, each with its own simple business logic. Still, choosing either PaaS or IaaS for microservices is an open question. Below is a table that demonstrates six major differences when implementing microservices on IaaS vs. PaaS (such as Cloud Foundry).
Monolithic approach may become a bottleneck when you build large-scale systems, prolonging their release cycles. Scaling “logical” parts of an app requires significant resources (upgrades/migrations), you need to re-write and re-deploy the entire monolith to try a new infrastructure, and so on.
Microservices architectures offer a better alternative, since any of splitted services can be scaled and deployed separately. In addition, you can use different programming languages for different parts of your system, several teams can simultaneously work on different modules, each module can be customized to provide better fault tolerance, etc.
(Great thanks to Matt Stine of Pivotal and John Wetherill of ActiveState for posting on this topic and promoting the microservices idea within the Cloud Foundry community!)
Bare infrastructure or a platform?
However, what you get out of microservices-based architectures depends on your cloud infrastructure choices, as well. For instance, running an application on bare IaaS is more affordable, but you will need a DevOps team to maintain it. An automated PaaS is a bigger investment, but it can shrink release cycles from weeks to hours and even eliminate some downsides of the microservices model.
The table below lists six major differences between microservices implementations on IaaS and PaaS (Cloud Foundry), based on our experience.
|1. One service for one job||Every service is deployed on an IaaS instance (a physical or virtual machine) by a QA/DevOps team. DevOps are responsible for configuring valid communication interfaces. Scalability is provided by the DevOps team.||A service (or an application) is deployed by a developer. Scalability can be controlled by a developer. Communication endpoints are served by the PaaS. You just need to assign a unique name to the service in the root PaaS domain. You do not have to think about IaaS. Instead, you will be able to focus on implementing business logic for each of the services.|
|2. Using different tools to implement different services||The DevOps team needs to configure an application runtime on IaaS instances.||An application runtime is automatically deployed in a PaaS container.|
|3. Loose coupling||The DevOps team manages IaaS instances used for service deployment.||PaaS containers are isolated elements for application deployment. Container life cycle is managed by the PaaS.|
|4. Independency of developers||DevOps may need to create multiple IaaS environments for each of the development groups.||When a PaaS is used, development groups can be managed as “organization” units. Deployments for development and testing can be arranged as “spaces”. You can have multiple “organizations” and “spaces” in a single PaaS deployment.|
|5. Continuous delivery||DevOps engineers need to install and configure build-automation tools and integrate them with a project repository to provide continuous delivery.||Build-automation solution can be deployed in Cloud Foundry as a regular application. This reduces the time necessary to provide continuous delivery for a project—compared to IaaS.|
|6. Integration with external services||The DevOps team deploys external services. Applications connect to external services using properties.||A service broker of the PaaS can be used to deploy and publish some external services. Service binding makes it easier to connect an application instance to external services.|
This blog post is a part of my latest research paper, “Microservices Architecture: The Pros, Cons, and How It Compares to Monolithic Approaches (+ Cloud Foundry Examples).” There, I overview the inner workings of microservices implementations, explain how the Cloud Foundry PaaS helps to solve the associated challenges, and provide code samples for running and scaling microservices apps on CF. Feel free to share your feedback in the comments.
About the author: Sergey Sverchkov has over 15 years of experience in building complex software architectures, database development, and data migration. Since 1996, Sergey has created dozens of enterprise solutions for big data analysis and BI that utilize distributed frameworks (such as Hadoop) and are deployed in virtualized infrastructures (including Amazon, Eucalyptus, Joyent, Rackspace, RightScale, Microsoft Azure, etc.).No Comments