Do you ever want something so badly that you might just fall into a trap trying to get it? That cheese looks awfully yum…whack! Oops :(
When speed = haste
When speed = haste we blind ourselves to potential pitfalls. One area today of much haste in many enterprise IT organizations is, you guessed it, the move to the cloud. I was visiting a customer today, and I was told a familiar story: Their application team has built a new application proof-of-concept on AWS, and the line of business is going to fund this app to move ahead. The familiar part of the story line is that this was all achieved in X weeks instead of X months. With impressive results, developers are soon pulling the rest of IT to do cloud with an executive push.
Embracing cloud native is a great thing, but doing so with this haste is running right into the palm of AWS’s hand. Not to pick on AWS, this can happen anywhere, but it’s most likely to happen at AWS because they’re the incumbent choice, and there are so many services to help developers deliver something cloud-native quickly.
To developers, these AWS services look like candy to Garfield on halloween. Unsuspectingly, many will never see the trap. Why? Because the lock-in police within the IT organization are patrolling I&O, while the lock-in felons have cleverly gone to work over on the application developers.
“The new ‘lock-in’ is from developers,
not infrastructure and operations”
I often talk about the move to cloud being led by developers and the devops trend; however, I hadn’t put 2 & 2 together quite like I did today with respect to lock-in. Although, I do often preach about how 80-odd percent of enterprises are targeting the hybrid cloud model, and how to make hybrid cloud a true IT platform, there must be portability across clouds, I guess I didn’t see the inverse of that concern.
That brings us to discussing the solution. How to achieve portability and a hybrid cloud IT platform with, less but not absolutely no, lock-in.
Let’s just examine the main public cloud business models for their services.
- First, nearly everyone is very familiar with IaaS. It’s offered at almost all big clouds, certainly the main 3.
- Then, there is the managed service model, where the cloud provider will usually take the many popular open-source software projects and offer them as individual managed services.
- Finally, there are the services that are homegrown or customized by the provider and offered as a service.
This is a decent summary of the main service models, but certainly not the only things that cloud providers can offer. Some other interesting examples include: AWS offers Direct Connect; GCP differentiates with its own high-speed global network to interconnect regions; Azure has the broadest compliance coverage. Anyway, if you understand the 3 models above, you can probably easily grasp what’s coming next… That developers that use customized, homegrown services are clearly locking themselves in the most.
Getting conscious about lock-in
So should you never use these customized cloud services? Of course you should if it is really worth it, but do it consciously. Obviously, services that are unique prevent apps that touch them from being very portable across your hybrid cloud platform.
The good news is that most cloud services today, have an open source project that matches most of what any service can do. If not, there is still a good chance that you can achieve similar benefit with a combination of open source projects, or vendor products based on such projects.
Bring your own stack
Perhaps the main thing that enables IT to go from multi cloud to consciously building a universal hybrid cloud platform is a unified toolchain and unified policy. Some systems’ policy unification can be achieved with meta-orchestrators that work across multiple clouds like Red Hat CloudForms and RightScale, but they have their limitations. Using the many benefits of public and private cloud IaaS, you can still control the application and devops stack to achieve portability and mitigate lock-in by bringing your own full stack that sits atop of any IaaS.
Anyone can do multi cloud. Throw in a little bit of this, and a little bit of that. But the recipe for a happier hybrid cloud seems to be known to some organizations, but not to all, so let’s have a look at how to do cloud with less lock-in and more portability.
Embrace cloud IaaS as a base for your devops stack, but use other cloud services sparingly:
- Bring your own IaaS automation and abstraction (such as Terraform and config management tools like Puppet, Chef, Ansible, etc.)
- Lock in to cloud services consciously when they are unique and necessary for business advantage
- For services that have open source tool equivalents, bring your own tool or at least use a managed service that has the generic API
Start with 2 clouds instead of one. This will…
- Prevent you from tethering yourself to just one partner for cloud innovation & economics
- Force the application cluster / stack to be portable
- Force the DevOps workflows to be portable
- Force designing for resiliency and scale early on
Take the naïve out of cloud native
If your business case for cloud is that your developers’ new-found speed is knocking the socks off of your executives, then maybe have a closer look.
There is a better way to “do cloud” with portable apps, automation, and software-defined infrastructure atop of any IaaS, and even better, there is actually plenty of help. Check out the cloud-native computing foundation that Juniper and many other vendors recently joined and for your unified toolchain check out some of Juniper’s cloud software portfolio that can fit equally well across your public/private/ hybrid cloud venues such as AppFormix, vSRX, vMX and Contrail Networking built from OpenContrail.