This post is obsolete

This blog post is quite old, and a lot has changed since then. Meanwhile, I have changed employer, blogging platform, software stack, infrastructure, interests, and more.
You will probably find more recent and relevant information about the topics discussed here elsewhere.
Still, this content is provided here for historical reasons, but please don’t expect it to be current or authoritative at this point.
Thanks for stopping by!

The Difference Between a Standard and a Preferred Vendor


Recently, I attended a customer workshop where the customer declared that they standardized on x86, VMware and Linux.

That got me and my colleague thinking about what standardization really means and whether that actually makes sense.

The workshop was actually about defining a PaaS platform for the customer, and early in the process they just said: Fine, but it’s gonna be x86, VMware and Linux, because that’s our standard. WTF?

What Standards are Not

x86 is not a standard, it’s a processor architecture. VMware is not a standard, it’s a hypervisor implementation. And Linux is not a standard either, it’s an operating system.

J2EE is a standard, and the only one that is relevant to the particular project we were talking about: The goal was to create a Private PaaS Cloud for the customer, and J2EE is the standard that establishes the interface between the PaaS cloud as a service provider and their customers. Nothing else.

Once the interface between you and your internal customers is defined through a standard, it doesn’t matter what processor architecture, what hypervisor or what OS you are using to deliver against that standard. At least not to the consumers of your service, because the purpose of defining an interface is to abstract away all implementation details from your customer so you get to choose the best possible way to provide your service!

Standardization is a Common Language

Standardization is about agreeing on a common language so you’re free to use whatever you want to do your job. Standardization should not dictate your choice of CPU, Hypervisor or OS. It’s that simple.

So the next time you say “We have standardized on x86”, you’re really saying: We have limited our choices of CPUs and stopped thinking about them. Think twice because you may be missing a lot of opportunity.

And that brings us to another important principle in building clouds: After you define the standard that abstracts your service away from your customers, there’s no point in using any type of standardization at a lower level than that. This is best explained in this blog post about PaaS is not Middleware over IaaS.

Which means: If you’re about to create a PaaS service, you should do whatever is necessary to make it as efficient as possible, without resorting to someone else’s service. Because that would limit your choices, limit your service level and limit the opportunities you have in making your approach to delivering your service as efficient as possible.

So here are some good architecture principles for building clouds and establishing standards:

  • Standardize on one thing only: Your interface between you, the service supplier and your customers, the service consumers.

  • Don’t accept any standardization below the level of the interface you provide, because it limits your choices and your opportunity to deliver quality.

  • Learn to distinguish standardization from choosing a preferred vendor. They are different things with different purposes.

And here’s the plan on how to build clouds:

  • Define the service that you want to deliver as a standard. It could be Database as a Service, J2EE as a service or even dogfood as a service.

  • Make that service definition as product agnostic as possible. It should survice at least ten years of usage.

  • Stop caring about your service consumers (they have the manual, right?) and start optimizing the heck out of your service delivery stack, without any restrictions on what technologies, vendors or stuff you use.

Really, it’s that simple. But it’s not “We have standardized on x86, VMware and Linux.”


Commenting is currently not available, because I’d like to avoid cookies on this site. I may or may not endeavor into building my own commenting system at some time, who knows?

Meanwhile, please use the Contact form to send me your comments.

Thank you!


This is the blog of Constantin Gonzalez, a Solutions Architect at Amazon Web Services, with more than 25 years of IT experience.

The views expressed in this blog are my own and do not necessarily reflect the views of my current or previous employers.

Copyright © 2022 – Constantin Gonzalez – Some rights reserved.
By using this site you agree to not hold the author responsible for anything related to this site. See Site Info/Imprint for details and our information policy.

This site was built using Pelican, which is written in Python, using a homegrown theme that borrows heavily from Elegant. It is hosted on Amazon S3 and distributed through Amazon CloudFront.