AWS needs to step up its DevOps game - and a few other takeaways from the new Gartner Magic Quadrant

AWS needs to step up its DevOps game - and a few other takeaways from the new Gartner Magic Quadrant

On September 1st, Gartner released the first edition of the Magic Quadrant for Cloud Infrastructure and Platform Services. This Magic Quadrant contained many interesting analyses, but one stood out to me - not in the least because I’ve experienced it firsthand. AWS needs to step up its DevOps game.

You can find the full Gartner report here.

CIaaS to CIPS

“Wait” you might say. “Doesn’t Gartner release a Magic Quadrant for public cloud every year?”. And yes, they they do. But it used to be called the Magic Quadrant for Cloud Infrastructure as a Service, or CIaaS. They deprecated that series in favor of the new Magic Quadrant for Cloud Infrastructure and Platform Services, or CIPS.

This is a logical, but significant change. CIaaS focused on the public cloud services that could replace the infrastructure in your existing data center; virtual machines, databases, networking, hard drives and so on. Every modern public cloud provider offers a strong IaaS foundation. But what differentiates the public cloud providers are their platform services, which are unavailable in most private clouds: databases as a service, infinite object storage, integrated monitoring, and so on. Using these additional PaaS offerings lead to higher availability, better security, better performance, more advanced features and better integrations, while reducing operational overhead. As such, the quality and broadness of these features often define the value of a public cloud provider to a business.

From the report:

The scope of the Magic Quadrant for CIPS includes IaaS and integrated platform as a service (PaaS) platforms. These include application PaaS (aPaaS), functions as a service (FaaS), database PaaS (dbPaaS), application developer PaaS (adPaaS) and industrialized private cloud offerings that are often deployed in enterprise data centers.

Development tools

From that statement, the term ‘application developer PaaS (adPaaS)’ stood out to me. To fully benefit from the features offered by public cloud, application developers will need to deploy new features often, quickly, and consistently. Often a new feature release requires changes in the infrastructure as well: think deploying new SQS queues or S3 buckets, or updating the launch configuration of an autoscaling group.

To optimize the development workflow and receive quick feedback on new features, deployment tools often integrate with version control systems (can we just say Git? Everybody uses Git). Examples are automatically running tests and integrations, automatically deploying branches to test environments, and automatic notifications and rollbacks when an issue arises.

The functionality for managing all these automated steps is provided by application developer tools. In AWS, these can generally be recognized by their Code prefix: CodePipeline, CodeCommit, CodeBuild, CodeDeploy and a few others.

For application developers with a DevOps workflow, the quality and feature richness of these tools is even more significant. For these users, every step in the development and deployment flow needs to be automated and executed as soon as possible. And new solutions or insights for the deployment pipeline need to be tested and deployed as soon as possible as well. For this group of developers, the versatility of the tooling might be one of the biggest differentiators in choosing a public cloud.

From the report:

All the providers offer basic cloud IaaS — compute, storage and networking resources as a service. They also offer additional value-added capabilities, notably cloud software infrastructure services — typically middleware and databases as a service — including PaaS capabilities. These services, along with IT operations management (ITOM) capabilities as a service (especially DevOps-related services), are a vital differentiator in the market, especially for Mode 2 agile IT buyers.

Current state

This is a significant risk for AWS - because their tooling simply is not that versatile.

The biggest hurdle to dynamic workflows is Amazon’s CodePipeline - ostensibly the glue and management layer for all the other application development services in the AWS ecosystem. This is a diagram from CodePipeline’s product page:

CodePipeline

From this overview we can deduce that CodePipeline should be able to take your source code, build it, test it, deploy it to a staging environment, and promote it to a production environment. And this is definitely possible, as long as you:

  • Use one of the supported Git providers (not self-hosted or GitLab)
  • Build based on branches, not tags
  • Always use the same branch
  • Don’t have parallel builds
  • Don’t need a choice step
  • … and so on

But it’s not all doom and gloom. CodePipeline is also:

  • One of the few pipeline providers (maybe the only one) that can be completely defined in code (CloudFormation)
  • Completely serverless
  • Pay as you go and very affordable ($1.00 per pipeline per month)

A recent customer had some requirements that couldn’t be fulfilled by CodePipeline. We didn’t want to host and maintain a Jenkins or GitLab server (hooray for serverless), and didn’t want to pay the subscription cost for online hosted services because they are very expensive. So we ended up building our own deployment management solution. The end result is shown below. I wish I was kidding.

CICD Diagram

In a nutshell, because CodePipeline does not allow for dynamic pipelines and does not have a dynamic frontend, we had to build Lambda functions for the different deployment steps and a frontend to access these functions. We used DynamoDB to store history (for rollbacks), CodeBuild for compilation and deployments, and Cognito for user management.

In researching and designing the solution above, I’ve seen many suggestions to adjust your Git workflow to better fit the CodePipeline feature set. The worst of these is “use branches, not tags” (related to another example than the one above). These “solutions” would force you to adjust your developer workflow to the tooling you’re using, which should never be necessary.

The Azure side of things

I am not very familiar with Azure, but I hear and read great things about their family of deployment tools: Azure DevOps. Additionally, Microsoft made the extremely smart strategic decision to acquire GitHub in 2018. GitHub Actions is a great example of how powerful DevOps tools should work, and having that in their portfolio bodes well for Microsoft’s future.

From the report:

Microsoft is making a concerted effort to better serve software developers, particularly through its efforts with OSS. Microsoft leads the hyperscale cloud providers in terms of market share in the application developer PaaS segment with its suite of tools that include Azure DevOps and Github.

An opportunity to differentiate

For AWS, the risk of being behind in this segment might actually be larger than just being a bit less appealing to developers. In fact, the developers tools segment might become the big differentiator between the leaders in the CIPS sector. Let me explain.

Evolving Market

In this diagram you see a number common technologies available in public clouds. On the left you see technology used by almost everyone: there are very few workloads that don’t use some virtual machines, networking, databases or object storage solutions. These technologies are very mature and offered by every cloud provider. This means it is very hard to differentiate in this area.

On the right you see more exotic technologies like quantum computing and machine learning. There are relatively few businesses using these technologies, and the market is still evolving. It is a lot easier to differentiate or to come up with a completely new service offering in this area. The demand will be low, however, so public cloud providers won’t be winning over a large segment of the public cloud market with these technologies.

The sweet spot is in the middle - for these technologies the market is still evolving, but there is also significant demand for solutions in this space. Just google for “Deployment pipeline software” and count the number of providers. Having a solid offering of versatile deployment tools will help win over application builders, software development managers, product managers, or, as Gartner said: “Mode 2 agile IT buyers”.

Next steps

So what’s next for AWS? Well, Gartner marked them as the absolute leader on both the ‘Completeness of Vision’ and ‘Ability to Execute’ axes. In this case, they need to execute. They can do this in two ways.

First option: empower and motivate the Developer Services team to significantly extend the feature set of CodePipeline or release them as a new, more powerful service (AWS DevOps?).

Or, my preferred suggestion: acquire GitLab and offer its functionality as a new, serverless, pay-as-you-go, fully managed and cost-effective AWS service (AWS DevOps?).

This would bring AWS back to the frontlines of developer services and make them a worthy adversary to Azure DevOps. It would technically be a war-by-proxy between GitHub and GitLab - our own nerdy version of Batman vs. Superman!

Batman vs Superman

Follow-up

A few weeks after publishing this post, I wrote a follow-up article: Features of a proper pipeline service. In this article we explore the functionality AWS CodePipeline should offer to blow away all competition.

Other thoughts about the Magic Quadrant

There is a lot more to the new Magic Quadrant for Cloud Infrastructure and Platform Services report. Some tidbits that jumped out:

1. Managed and professional services are an optional but important accelerator for customer success

I wrote a post about this exactly two weeks ago and could not agree more. Read it here: the difference between managed services and professional services - and why you need both.

2. Microsoft has the lowest ratio of availability zones to regions of any vendor in this Magic Quadrant

I was not aware of this. There were some other related statements:

  1. Google’s much-vaunted network capabilities have been the source of a number of GCP outages during the last year, with devastating impact on customers. One outage was multiregional in scope, affecting GCP customers and Google consumer services, such as G Suite and YouTube. This resulted in complete GCP network unavailability for some customers.
  2. The Oracle Cloud Infrastructure (OCI) data centers are grouped into regions, some having only one availability zone, such as those in Australia, Brazil, Canada, India, Japan, the Netherlands, Saudi Arabia, South Korea and Switzerland. Regions with three availability zones are located in the east and west of the U.S., Germany, and the U.K.
  3. AWS groups its data centers into regions, most of which contain at least three availability zones (data centers).

The fact that AWS has a multi-az solution in all of their regions - and at least three AZs in most - really speaks to their long-term vision and explains why region-impacting downtime is very rare in AWS.

3. Microsoft does not provide any form of guaranteed capacity to customers; even prepaid agreements and reserved instances are not capacity guarantees

This renders at least 50% of the arguments for capacity reservation to dust.

4. Oracle delivers all capabilities simultaneously into all regions worldwide, unlike its competitors

I’m impressed.

Get in touch

If you have questions or remarks, or would just like to get in touch, you can find me on Twitter and LinkedIn.

Luc van Donkersgoed
Luc van Donkersgoed