2 and SOC 3 reports and laws such as HIPAA. This effort to
meet these standards involves time and expertise, along
with both an upfront investment and ongoing operational
costs, plus bringing onboard some sophisticated skills,
which are neither always available nor cheap.
In many cases, businesses simply might not have the capac-
ity to achieve the required compliance in their own opera-
tions. Plus, moving to the cloud might enable a business to
strategically expand and extend its processes, since it does
not need to worry about the compliance of its platform and
underlying infrastructure.
CSP leaders, such as Amazon AWS, Microsoft Azure and
Google Cloud, provide clients with great compliance ser-
vices. These CSPs take on all the burdens and struggles of
making sure their services comply, and stay in compliance
with international, national and industry specific frame-
works, such as FIPS 140-2, ISO 27001, ISO 27017, ISO
27018, ISO 9001, etc. These CSP leaders also periodically
provide attestation of their compliance.
In most cases, compliance requires not only the platforms
but also the underlying infrastructure to be compliant. All
services running on top of that infrastructure directly
depend on it, and therefore cannot be moved easily, if at all,
out of that CSP. This risks a complete CSP vendor lock-in. It
cannot be avoided by running workloads in a hybrid or mul-
ticloud deployment model, unless you establish a well archi-
tected cloud exit strategy, as described in the post "Hybrid
and Multicloud Deployment Models to Support a Cloud Exit
Strategy."
For an enterprise with compliance requirements, using
attestation that is acceptable to their auditors and credi-
tors, moving to a compliant cloud provider (with their
requirements) may outweigh the vendor lock-in risk, strate-
gically, tactically and operationally. Most large CSPs are
keen to stay compliant, and have the dedicated resources to
achieve this goal. CSPs, especially the leaders, simply have
more compliance capacity and continuity than individual
private data centers and private clouds.
Emerging Application Architectures
Lately, we have seen a strong trend from many enterprises,
to adopt microservice application architectures. Some have
76 | THE DOPPLER |
FALL 2019
a microservice first strategy. They mandate that all newly
developed applications should adopt serverless architec-
ture; or if that is not possible, then containers; or if neither
of those are possible, then the old way of classic application
architectures. Let us take a closer look at serverless and
container architectures from the vendor lock-in and added
business value perspectives.
Serverless
Serverless does not give clients any control over the plat-
form and the underlying infrastructure, nor any under-
standing of how it has been set up, or of how to move
serverless applications from one platform to another.
For example, AWS Lambda, Azure Functions and Google
Functions only show users how to build and deploy an
application. The application itself is solely dependent on
the underlying infrastructure that only the CSP can access
and control. Although most serverless applications are writ-
ten in open source or non-proprietary programming lan-
guages, they might not, or most likely will not, work on
another CSP platform, because of the complexity of the
infrastructure dependencies.
It might not be worth the effort of analyzing the code using
the “6 Rs” application migration effort. You most likely will
need to rearchitect and redevelop the application, given all
the dependencies and services it interacts with, which are
specific to the cloud provider.
We can state with great confidence that serverless applica-
tions strategically have high, if not complete, risk of CSP
vendor lock-in.
On the other hand, the added value gained from adopting
serverless applications is very high at the operational and
tactical levels. The benefits in these areas include, for exam-
ple: reduced operational costs and time to market, ease of
deployment, more time to design the UX, better scalability,
more efficiency and improved latency and flexibility.
Containers
Container architecture gives clients more control over the
technology and the platform. It also provides more flexibil-
ity in using supporting services, such as orchestrators and
service meshes.