Choosing the right Containers-as-a-Service (CaaS) – or not

The emergence of cloud native development and containers has redefined how software is developed. But not all organizations have the resources or expertise to set up the required infrastructure to support a containerized application. Luckily, cloud vendors offer Containers-as-a-Service to help developers to capitalize on the benefits of cloud native development.

All three leading cloud providers have CaaS products but choosing the right one can be a challenge. While everyone has different requirements, it is always beneficial to understand what solutions others are using and why, to help inform decisions.

Based on research from /Data’s recent Developer Economics survey, we have discovered that there are a few factors that drive developers to choose one CaaS over another:

familiarity with tools and languages
integration with other systems
support and documentation
ease and speed of development.

While there were other reasons for developers to consider when adopting a platform, the percentage of developers that considered these four factors important is noticeably different across the three leaders. Some of the other sixteen factors that are tracked in the research include:

pricing
community
learning curve
suitability and feature set
performance
scalability

Not all CaaS platforms are selected for the same reasons though. Developers that chose AWS Elastic Container Service were more likely to choose it because of its integration with other systems. This is a reason to choose AWS ECS for 34% of developers using it, compared to 29% and 28% for Azure and Google. Amazon not only has a vast array of tools and services, they also have a robust partner network. The options are so great they have their own service marketplace and have even released a Cloud Map service to help developers discover and manage it all.

Developers tend to favor Google Container Engine (GCE) because it is easy to use and well documented. Forty five percent of GCE developers chose it in part because of the support and documentation and 36% because of ease and speed of development. We tend to find that developers are consistently happy with the support and documentation that Google provides to their developer community. This satisfaction is an important reason for Google Container Engine users to choose the platform.

For Azure Container Service, developers like the fact that they can use the tools and languages that they are familiar with. Azure developers are 7 and 12 percentage points more likely to choose Azure Container Service for this reason than Amazon and Google respectively. Our research shows that Microsoft developers are relatively brand loyal so Azure has made it easy for developers to use Microsoft tools for container development and management. Azure has enabled developers to develop using Docker containers and Visual Studio, tools to deploy code to Azure Container Service with a simple command. They have also made it possible to deploy Docker containers to Windows Servers. Finally integration with Active Directory enables loyal Microsoft developers to use existing authentication policies and technologies .

At the end of the day, most developers are looking for a platform that is easy to use and fits with their current strategy and infrastructure, whether it is though integrations, support, or the ability to use the tools that they are comfortable with.

Containers: Is it really a choice of either or?

While each solution has unique benefits, our analysis also found that many developers were using more than one leading CaaS and in some cases three. Seven percent of developers using a CaaS were using all three of the leading platforms while 46% were using two.

Our data verifies what you may already suspect based on your own experiences: more than half of backend developers are pursuing a multi cloud strategy, choosing not to commit to a single provider.

There are a number of benefits to a multi-cloud solution that are driving this trend. IT organizations can avoid vendor lockin if teams develop for a multi cloud environment. This approach forces developers to build without relying on vendor specific services, reducing switching costs. Multi-cloud approaches also enables organizations to optimize their infrastructure. Developers and operations pro’s can leverage the strengths of each cloud depending on the requirements of various workloads and applications. Greater resilience is also a key benefit to consider. This is especially important in denial of service attacks where compute resources can be overwhelmed with fake requests. With a backup cloud ready and waiting, workloads can just shift to the backup cloud.

The choice of either one CaaS or the other will become even less relevant in the future as leading vendors are all standardizing on Kubernetes. Amazon and Azure are promoting Kubenetes-specific CaaS offerings to focus more on Kubernetes as the underlying orchestration engine. Azure is actually migrating all its users to the Kubernetes service. With Kubernetes the standard orchestration engine, migrating apps and container across cloud providers becomes much easier.

We are also seeing Amazon and Azure working to make it more convenient to develop using containers and Kubernetes. Both firms are offering clusterless or serverless Kubernetes services such as Fargate from AWS and Azure Container Instance. These solutions enable developers to just deploy containers without having to worry about servers or clusters. This approach will make it easier for developers but the additional level of abstraction also reduces flexibility and increases switching costs.

Amazon’s open sourcing of Firecracker, the micro VM that supports the serverless platform Lambda and Fargate, will be another interesting development to watch. This may prove to be Amazon’s response to Kubernetes but for the serverless market. While still a ways off this could lead to a serverless ecosystem that is just as flexible as the container landscape.

What do you think?

Do you feel strongly about the container solution you are using?

Or perhaps you feel poorly about certain other containers.

Let us know about it and have your voice heard by taking the Developer Economics survey.

True Cloud-native Development Has Yet To Go Mainstream

WHAT IS CLOUD-NATIVE AND WHY IS IT IMPORTANT?

The cloud-native computing foundation (CNCF) defines it as ”using an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization.”

The first step towards cloud native computing is implementing containers so resources can be shared with other apps. Containers can also be spun up much faster than VM’s and are portable so they will run the same in any environment. In addition, they offer another layer of isolation from the host environment so applications can be built more securely. These benefits have broad appeal and half of backend developers are using either containers or a service that leverages containers under the hood, such as serverless platforms or cloud functions.

While the benefits of containers are significant it is the combination of containers, microservices and orchestration that enables greater efficiency in the use of cloud computing resources. For example, microservices with heavy workloads can scale out without having to scale the entire application. Also, services that are not required for current workloads can be shut down, thus optimising pay-as-you-go business models and reducing costs. Finally, the scalability and portability of containers combined with orchestration leads to distributed systems that offer greater resiliency. If there is a problem on one server, another instance of the microservers can be spun-up to take its place.

Our survey found that just 43% of developers are using containers plus container orchestration tools and management platforms, leaving 57% managing their own container deployments. Developers who are not leveraging orchestration tools may just be moving existing applications into containers or building simple apps with a few containers that can be managed manually. Cloud native apps have to not only leverage containers but should be designed specifically to capitalise on the efficiencies that the cloud offers. Developers that are using containers but not using orchestration tools, or platforms with built in orchestration, are not really building cloud native apps.

Cloud-native is more than just migrating to the cloud or containerising a monolithic app. Lifting and shifting an existing application and plopping it in a container is not a modern approach. Historically, as new computing platforms emerge, there is a temptation to take the code that already exists and just port it to the new platform. While you may realise some benefits, the true value of the new platform is missed. This is a common mistake developers make as platforms become popular. The growth phase of mobile apps is a case in point. Once everyone wanted apps on their smartphones, developers ported desktop apps to mobile which were not designed to capitalise on the unique benefits or mobility leading to poor experiences.

DEVELOPERS HAVE MULTIPLE OPTIONS TO BE TRULY CLOUD NATIVE

New services are emerging that offer various levels of abstraction that makes it easier for developers to take advantage of cloud-native architecture. Containers-as-a-Service (CaaS), serverless solutions and cloud functions are making cloud-native development more accessible. Developers can deploy containers and orchestration engines on their own or leverage frameworks provided by CaaS offerings. They can also use serverless platforms so that they don’t have to touch a server at all but still get the benefit of orchestrated containers and dynamic services. These solutions are becoming quite popular: 47% of backend developers are using these functions or serverless architecture.

With the flexibility of native cloud development and microservices, developers are free to use the most appropriate tools and services to build discrete components of their apps or services. The spectrum of abstraction and strengths of each approach enable developers to optimise their applications and development time by using the best technology for the job. For example, cloud native developers can use serverless for running short, event-driven processes and containers for running longer more robust code. Additional services are coming to market to fill niches in the spectrum of cloud-native offerings presenting even more options for developers. For example, AWS Fargate is filling the gap between CaaS and serverless where developers still have access to the server but don’t have to worry about containers. The results from our survey confirm that many developers are using multiple solutions to optimise resources. In fact, 32% of developers using containers are also using serverless and 40% of true cloud native developers leveraging orchestration tools and platforms are also running serverless.

Containers: Is it really a choice of either or?

What do you think?

WHAT IS CLOUD-NATIVE AND WHY IS IT IMPORTANT?

DEVELOPERS HAVE MULTIPLE OPTIONS TO BE TRULY CLOUD NATIVE

Want more insights plus an extra graph?