AWS Partner Network (APN) Blog
Solving Next-Gen Problems for Next-Gen Cloud Adopters
By Brett Moss, SVP and General Manager of Hyperscale Cloud at Ensono
Looking back, October 2008 is as good a time as any to designate as the beginning of the first generation of mass adoption of the cloud.
It was during that time that Amazon Web Services (AWS) removed the beta label from Amazon Elastic Compute Cloud (Amazon EC2) and officially provided a world of software developers with virtually unlimited storage and compute capacity, available on-demand and at low-cost. Those developers were off to the races—building more and more applications in the cloud, and taking advantage of the many features and services AWS began to add.
That first generation overcame the challenge of thinking of infrastructure as code. They learned to stop thinking of compute instances as precious snowflakes that required extensive recovery plans, and they started thinking of them as disposable resources that could—and should—be shut down at the first sign of trouble, and then automatically rebuilt.
The first generation of cloud adopters merged the practices of infrastructure automation and code deployment automation, so that the infrastructure running their apps was actually deployed by the frequent pushes coming from a code repository. They faced many challenges reckoning with the awesome power of AWS and pioneered cloud engineering in the process.
If we want to point to the zenith of the first generation of cloud adoption, we could do worse than July 2011, when Netflix announced it had developed a set of tools (the Simian Army) that randomly terminated production compute instances during working hours in order to make sure engineers designed their use of AWS for fault tolerance and rapid, automated recovery. There’s nothing like taking off the training wheels to get the most out of auto scaling groups.
The Next Generation
The first generation of cloud adopters had a massive advantage over the mid-market and enterprise customers who came after them—their applications were born in the cloud. They did not have years, even decades, of legacy infrastructure running these new apps, so they were largely unencumbered to go “all-in” on AWS.
Today, a new generation of companies is navigating a journey to AWS, and those companies have a very different set of challenges to overcome.
Mid-market and enterprise customers embraced AWS as a viable execution venue for their workloads sometime around 2015, when Capital One and GE stood on the keynote stage at re:Invent and declared themselves all-in on AWS. Of course, there had been shadow IT and all sorts of testing and tinkering happening prior to then, but the data indicates later adopters only accelerated their movement to the cloud in the past three years or so.
This next generation of adoption brings a new generation of challenges. At Ensono, an Advanced AWS Consulting Partner, our stock-in-trade is this set of challenges. We are a company built to work with mid-market and enterprise clients that were not born in the cloud and run production applications on myriad computing systems. Our clients simultaneously run bare metal servers, virtualized servers, company data centers, hosted systems, mainframes, and AWS. Our job, working with clients, is to make it all work together to achieve whatever outcomes they define as critical to their businesses.
With extensive installed IT—called “technical debt” on a bad day and “legacy” on a good day—our clients cannot simply throw everything away and uproot to AWS overnight. They hold equipment and data centers as assets on their balance sheets; many of their applications are not ready to support the advanced capabilities of AWS; and their entire business depends on SAP estates that took 20 years to get fully tuned. Most do not yet have the in-house skills to stand up to the Simian Army randomly switching off their infrastructure.
Let’s look at two examples we frequently encounter working with the new generation of AWS users.
Enterprise Applications in the Cloud
The first challenge we encounter concerns how to use AWS for enterprise applications. For our clients, these apps are the central nervous systems of their companies. The idea of making changes to SAP and Microsoft installations sends chills down the spines, but AWS provides a compelling option for these applications. We work with clients every day to migrate and operate in the cloud, minimizing disruption to their businesses.
SAP customers are looking at how to make the transition to HANA after SAP stopped supporting other databases for its newest generation of business applications. Having spent many years honing the people, processes, and technology to make SAP deployments work the way they want, our clients are staring down the barrel of a wholesale database migration, and they have to do it without taking down the operations of their company. These clients are looking for any way to de-risk the process, and Ensono developed a dedicated practice around using AWS technology to assist clients in this transition.
Our approach focuses on three outcomes: fast migration, reduced capital expenditures, and reduced operating expenses. To reduce the overall migration time, Ensono works with AWS in a Rapid Migration Methodology, a set of tools and best practices created by SAP and AWS that enables Ensono to help customers rapidly test migrations. Using this methodology, Ensono extracts and refactors database data to HANA format and deploys it into a test environment on AWS. In most cases, this can be done in a matter of days.
Once the testing is validated, Ensono’s SAP architects work with our peers at AWS and with the client to deploy an architecture on one of 12 SAP-certified HANA AWS instance types, including the powerful x1e, one of the largest instance types available today. These instances are some of the most unique in the industry for their ability to support the extensive in-memory requirements of the HANA database, and they help save our clients the requirement to procure new and expensive hardware.
Finally, once the SAP estate is in steady-state on AWS, we use our own cloud automation tooling to create ongoing economic efficiencies in the environment. For example, this might mean automatically turning on and off lower-level environments outside of business hours in order to reduce the infrastructure costs without compromising the availability of the SAP applications.
With Microsoft migrations, we work with clients to use AWS technology to achieve a leaner, lower-cost operation. Taking MS SQL as an example, AWS’s unique approach to providing low-latency connectivity between Availability Zones (AZs) enables Ensono engineers to reduce the required number of compute nodes for a SQL deployment by a factor of up to one-third. Testing has demonstrated a very consistent latency of under 2ms between AZs in any AWS region.
This means we can deploy an HA cluster with fewer nodes because we can use a two-node multi-AZ solution and forego the typical third node that would be required for DR. For .net shops, or clients running large SQL-specific apps like Dynamics, Biztalk, ERP, or those building data lakes on SQL, this ongoing cost reduction is considerable and does not come at the cost of compromised availability.
Installed IT
The final challenge we will discuss in this article is one that comes from clients with extensive and varied infrastructure systems in use. While the next generation of cloud adopters understand the many advantages of operating on AWS, they also understand that applications in their current forms may be most suited to a hybrid architecture.
At Ensono, we think about this along two axes: the venue, and the application.
To diagnose the most suitable venue for various tiers of an application, we use the paradigm of systems of record and systems of engagement. Because of Ensono’s strong pedigree managing mainframe and midrange infrastructure for large clients, we often work with companies running applications built for this kind of system.
Looking carefully at those applications, Ensono engineers make recommendations involving parsing out the tiers of an app in order to achieve the financial, agility, or operational goals of the client. It may be that a system of record can stay on a mainframe until the mainframe keels over (which, we all know, will probably have a long life cycle.) But, the system of engagement—say, a mobile front end—is a prime candidate for the cloud.
With architectural decisions in place, the client experience will largely depend on Ensono’s ability to communicate back to them in the language the matters most—that of the application itself. Regardless of the multiple types of infrastructure powering a workload, our job is to maintain the availability, security, and efficiencies of the app. In Ensono’s case, we achieve this using our own systems, collectively called Ensono M.O., that allow us to manage hybrid architectures through a single set of processes, automation, and reporting. For clients using AWS, M.O. connects directly into AWS and tools from APN Technology Partners that provide our clients the application-level view they require.
Next Steps
As AWS continues to disrupt the enormous base of installed infrastructure around the world, the next generation of adopters will use AWS tools, technology, and APN Partners to address their new challenges. They are not the same challenges faced by the first wave of born-in-the-cloud AWS users, but they are surmountable, and are being continually addressed so that companies can reap the benefits of the cloud.