Deciding on a cloud transition in the enterprise is about much more than choosing a new hosting technology. At Maersk, the move to cloud presented our IT organization with a golden opportunity to review our internal processes and ways of working. We re-engineered our policies for cloud delivery.
As with many IT teams, the traditional approach to infrastructure platform delivery forced us to move into a service provider mode in order to handle the complexity of running physical data centers. But as you move to public cloud, that complexity goes away.
You can offer new ways to host applications and enterprise workloads. And you can begin to offer self-service access to hosting infrastructure without concerning yourself with available physical resource capacity in the data center.
One concern that initially blocked Maersk from offering user self-service was that we didn't know how to ensure alignment with our architectural patterns and principles—and we were concerned about the technical debt that might accrue if our engineers didn't follow our internal principles.
At the same time, we didn’t want to slow anyone down by introducing too many architectural review boards or hand-overs. Instead, we developed a strong set of policies—we call them guardrails—to steer our engineers to build in an aligned way.
The guardrails
We compiled our guardrails into an internal, open-sourced document called the Cloud Architecture Principles, which describes how we build in the cloud. By open sourced, I mean that our engineering teams collaborated to create the document, it's accessible to all engineers, and anyone is welcome to share ideas about how to improve it.
We developed too many principles to share them all here—there are more than 40 in all—but here are some of the most important ones you should know:
- Infrastructure as code is required for all production environments. We ask all engineers to automate any infrastructure deployments to production. This allows our colleagues to determine the best time to automate.
- No manual changes to the production environment are allowed. This adds extra security to our environment. We ensure that all changes made to our customer-facing environments are conducted via code changes, and that all code changes are documented in code repositories and subject to peer review before we implement them.
- Data at rest must be encrypted. All data stored on our systems in the cloud must be encrypted—period.
- Protect all Internet-facing services. We apply a minimum set of protective measures in the form of web application firewalls, user authentication, and traditional firewalls to all Internet-facing services. We monitor this closely, since failure to follow this principle could lead to data leakage.
Collectively, the 40 policy guardrails form a reference for how our engineers should work with cloud infrastructure. They limit some choices, but also allow us to share best-practice configurations across teams.
Some of our guardrails are enforced by way of our cloud providers' policies. Others we report on internally and give advice to help our colleagues better understand the impact of not staying within the guardrails. Our engineers now consider these principles to be our north star for building in the public cloud.
[ Special Coverage: DevOps Enterprise Summit London 2019 ]
The challenges
As with many other enterprises, Maersk is transforming into agile-based technology delivery. The use of guardrails is fairly new to the organization, so we continue to put in extra effort to get our colleagues to support the concept. We want everyone to see our guardrails as a form of empowerment, not just as a compliance metric.
Another challenge we have faced is determining who's accountable for keeping our cloud-hosted product in compliance with our guardrails. Ultimately, we would like that to be the product owner's role. But the people filling those roles are often not technical, so they might not consider the implications of not staying within the guardrails. This is still a work in progress.
Guardrails get results
Our results so far have been great. By implementing self-service, and by shifting work left, we have reduced lead time to minutes rather than the previous 60 or more days for infrastructure deliveries. The guardrails have provided us with the assurance we need that we are staying aligned with our architectural principles.
If you're considering removing hand-overs between teams, then self-service and guardrails are the way to go. It's a great way to strike the right balance between empowering your individual engineers or product teams while ensuring a strong level of alignment with your company's standards.
Want to know more? Attend my conference session at DevOps Enterprise Summit: London, where I'll offer more tips on accelerating cloud delivery as part of your organization's DevOps transformation. The conference runs June 25-27.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
