“I saw … a city in the clouds.” – Luke Skywalker
I’ve been at Blue Sentry now for almost two full years, and have worked with AWS and DevOps teams for 10+ years before that in previous lives.
It’s hard to believe that it’s been that long — and even harder to believe just how inefficient companies can be on their cloud journey. But there is a solution, and, if followed, it can elevate your IT operations, engineering and application development to the luxury of Cloud City: Work with a long-term partner.
The biggest problem contributing to the majority of the inefficiency: Businesses don’t view cloud as a journey, but instead a series of projects to be executed on as workloads get retired, refactored, re-platformed or any of the other common drivers for a single workload migration.
The scenario plays out like this:
The business has a workload to migrate. IT either does it themselves, or hires a consulting partner to help do it. Workload gets migrated. Traditional IT thinking kicks in, and the workload is managed like a traditional data center workload. Essentially, servers are being rented from another provider. And while there are some inherent benefits to a migration such as high availability, operational expenditure, and the like, it falls significantly short from where a high performing organization, living in the cloud, should be.
There are some key best practices that I see as critical to ensuring success:
Establish a Cloud Center of Excellence. Blue Sentry previously has written a blog post about this here which I definitely recommend checking out, if you haven’t already. But even in organizations that establish a CCoE, I see execution issues. Organizational boundaries seep in, the wrong people from the organization get added to the team, the people that are added lack the skills to be effective members of the team. Consider the expertise needed for this highly critical component to a successful cloud journey, and honestly assess where your organization lies. If you have gaps (and you mostly likely will), strongly consider using a partner to serve as a long-term strategic adviser to your successful cloud journey.
Assess every part of your “Innovation Cycle.” In short, your innovation cycle is the way you take an idea and deliver it to the customer or end user. Things to consider here are how are ideas are captured, tracked, prioritized, implemented, tested and released. How fast is your innovation cycle? Do your application development teams have access to environments in which to innovate, at their fingertips? If the cycle is slow, consider the impact to your business. In this hyper-competitive environment, the most important feature any company has is how fast they can release new features. Sure, there are some exceptions where industry regulation controls competition, but the vast majority of us do not have that luxury.
So how do we speed up the innovation cycle? Agile practices and DevOps are the answer. Capture ideas in a product backlog. Break them down into small units of work. Release those units of work as they are ready. To do this, you’ll need a modern source management platform; an issue tracking system; teams organized to work as a cross functional DevOps group consisting of application engineers, QA analysts, and DevOps engineers; and a CI/CD pipeline.
And herein lies another pitfall. Do your DevOps engineers have the skills to build a sophisticated CI/CD pipeline? Do they even understand what the sequence of steps must be in order to do this responsibly? In my experience, most do not. In many cases, the leaders of the organization simply wave a magic wand, rename some titles and just like that, have anointed DevOps engineers. This is dead wrong. DevOps engineers are highly skilled, and difficult to find. If you have a team of operations engineers that do not have experience writing infrastructure as code, you need to stop and find engineers that do. This, again, is where a partner can help over the long haul. Using a partner to build the pipeline, establish the CI/CD process and manage the code deployment can free your staff to focus on more value add activities such as turning those ideas into releasable features more quickly.
And finally, one of the key failures I see is around next generation operations. How feature releases are managed and monitored in a “Cloud City” environment is so fundamentally different, that many organizations come up way short here. How you monitor services that come and go, running as serverless functions in things like AWS Lambda or in Docker containers popping up and disappearing just as quickly as they arrived, requires you to partner with a team that has that experience — or even more difficult, find, hire and retain your own team. Ask yourself, does monitoring actually add value to your features, or is it a necessary cost to ensure services remain available? We know that answer. And knowing that answer, why would your enterprise invest in expensive resources that will require you to find them, hire them and retain them?
I’ll leave you with that since I’m already wandering into TL:DR territory. However, all of these pitfalls are critical to avoid in order to build a luxurious “Cloud City.” A strong, long term partner can help you avoid them.