Today, I’d like to zoom out a bit and discuss the promises of Cloud and a bit about how you can use Cloud providers to grow your enterprise.
Cloud providers promise managed services:
- for infrastructure, platform, and even fully-managed applications
- backed by vast resources
- made available via API
- billed in small increments
Cloud providers are competing to offer high quality services that meet their customers’ needs at decreasing cost and increasing scale. They want you to offload whatever you consider undifferentiated heavy lifting to them. Sometimes this means running DNS, a database, a Hadoop cluster, or even an application’s identity provider.
Let’s focus on a simplified set of AWS’ (165!) service offerings that form the core of many Enterprises’ deployments:
Depending on your perspective, the ‘magic’ of these services and the Cloud operating model may be that the services:
- are available on-demand via API or console and you don’t have to wait for another team to provision and integrate a server to get something done or run a test
- scale from small to very large usage with documented limits
- leverage a common, Cloud-design and integrated Security service
- have been been tested with 10s, 100s, 1000s, or even more users with problems similar to yours and are (now) robust in addition to a community that can share knowledge around that implementation
- use of the service is billed only for the resources you consume and metered in units like seconds a virtual machine was running or gigabytes used in an object store
- offer ways to reduce operational costs through volume discounts, using discounted resources, and async architectures
The Real Magic: Optionality
Taken together, I think the real magic Cloud providers give you is optionality that helps you build the right thing. When you (re-)architect your applications to take advantage of the Cloud’s pay-for-what-you-use consumption model, you are positioned to:
- start on a proven, secure foundation
- test ideas quickly and for little cost
- understand the financials of your application’s scaling model
- scale your applications to meet customer demands
For example, let’s say you have an application that might be well-served by a document database. You might come up with three leading choices: ElasticSearch, Postgres (using jsonb), and MongoDB. Since AWS has a managed offering for each of these databases, you can try them out and see which works best. You are also in a good position to learn what the costs for your application will be before committing to an option because you solved the problem with each option and got a bill for each.
Suppose your application is working well and customers are adopting it. If the application autoscales its resource consumption with customer demand, then you should be able to accomplish a few really important things. First, the application should be able to acquire those resources from the cloud without a long-term commitment. Second, you can use cost and revenue data to build a financial model that tells you how much money you will make (or lose!) as customer volume scales on this application. Lastly, you can use this information to iterate on your architecture to improve costs as well as work with Cloud providers and other experts to verify capacity will be there when you need it.
In the past, you may have relied on extensive research to determine whether you commit to a new technology or an annual capacity modeling and CapEx cycle to place a BIG bet on where customer demand will be in 6 months. The Cloud changes that. Managed Cloud services help you Go Fast, Safely by providing options to tighten feedback loops and improve the long-lived architectural and financial decisions at the foundation of your enterprise. The only ‘trick’ is that you’ve got to be aware of your options and exercise them. But once you start exercising your optionality, you’ll probably find that you’re getting better outcomes for you and your customers. You also might feel more agile, to boot!
Receive #NoDrama articles in your inbox whenever they are published. Reply to Stephen and the QualiMente team when you want to dig deeper into a topic.