resources to build, implement and manage a solution that
could easily be acquired from, or run by a third party. For
example, in the on-premises world, almost every company
builds, runs and maintains significant infrastructure to sup-
port corporate email. Yet while email is a critical business
function, it is generally not part of the “secret sauce” that
differentiates a company’s product.
In the cloud world, you have the option to use managed ser-
vices to offload such functions, letting you focus on those
“secret sauce” services and functions that are core to your
business' success. Whether it takes the form of managed
cloud services such as DBaaS, higher-level capabilities like
the AI/ML offerings or third-party tooling, when done with
proper consideration, this offloading approach can greatly
improve your agility and velocity without compromising
your critical business functions or security posture.
3. Automate, Automate, Automate
One of the key steps to effectively leveraging cloud services
is to step away from the console and build everything you
can using automation. The end goal is to have the number
of manual steps in the deployment of applications and
infrastructure as close to zero as possible. While the pri-
mary benefits of taking this approach, such as consistency
and repeatability, are obvious, the secondary gains, such as
improved auditability, are just as important.
The process of automating your deployments can seem a
daunting task given the realities of often hundreds of com-
ponents, complex connectivity diagrams and tightly cou-
pled dependencies. In the majority of cases, the best way to
go is to start small and take an iterative approach, begin-
ning with a collection of scripts/playbooks, building on
them and eventually developing a full deployment
pipeline.
Embrace Immutability
The next logical step on your automation journey is to use
immutable infrastructure. This concept entails deploying
servers (or containers) that you never log into or modify
once deployed. If there is a bug fix, patch or configuration
change, you simply update your automation (image build
scripts, application deployment code, etc.) and redeploy.
Not only does immutable infrastructure enable you to
44 | THE DOPPLER |
SUMMER 2019
achieve greater reliability and consistency, it also signifi-
cantly reduces the attack surface, by removing the need to
expose services such as RDP/SSH on instances. The
destroy/deploy model also limits the total lifetime of any
one instance and thereby reduces the effective dwell time
of an attacker.
Consider Composability
As you design your cloud estates, you should also consider
the composability of your design. To borrow a rule from the
programming world, “Don't Repeat Yourself.” In other
words, design deployments so that the process becomes
more like building a Lego model, reusing various modules
— infrastructure as code (IaC), immutable infrastructure
and managed services — to achieve business goals. To
enable your modules to be “composable” you need to
ensure they are parameterized (e.g., there should be no
hard-coded variables). Composability allows your code to
be used in a broad range of situations.
4. Take a Security First Approach
The major CSPs run some of the most secure data centers
on the planet, and the majority of security issues that make
the news stem from a misconfiguration of services, or
poorly implemented guardrails by the consumers of public
cloud. To ensure that your business does not end up as
front page news for the wrong reasons, it is imperative that
security stops being a bolt-on option, and becomes a core
component of everything done in the cloud. This change is
easily the largest cultural evolution that has to occur in an
organization to ensure a successful and secure cloud jour-
ney. Implementing this principle involves ”shifting left”:
integrating security into the entire process, from initial
design through to Site Reliability Engineering (SRE). Your
security teams must learn more about infrastructure and
coding practices, and, conversely, your infrastructure and
development teams need to become knowledgeable about
security practices. A good example of this cross-domain
interaction can be found with secrets management. The
security team provides input on tool selection, by working
with both the development team, to implement secure cod-
ing practices for handling secrets, and with the infrastruc-
ture team, to deploy the tooling and application in a secure
and scalable manner.