Join Jeff Winesett for an in-depth discussion in this video Letting go of constraints, part of Amazon Web Services Essential Training.
- When you are ready to get started using the Cloud, among the steps you will invariably take is to try to determine what resources you're going to need. If you already have existing systems running in a non-Cloud environment, you might start by attempting to map your existing resources to those available in the Cloud. Most of the time, such an exercise will reveal that the Cloud does not have an exact specification match to your existing resources. The exact specifications of your existing on-premise infrastructure is no longer a constraint you have to work within.
The Cloud provides myriad building blocks from which you construct your system, and they become even more powerful when you combine them with the Cloud's on-demand provisioning model. Even if you might not get an exact replica of your existing hardware in the Cloud environment, you have the ability to quickly and easily get more of these resources in the Cloud to compensate that need. This is all structured purposefully, with scalability in mind. For example, if you find that there is not a Cloud server type that has the exact or greater amount of RAM you require on a single server, you should think about ways you could distribute that need across multiple servers, by rethinking your application architecture, or perhaps by leveraging other available Cloud services, like a distributed memory cache, something like AWS ElastiCache.
Or if you find that your database requires more input/output operations per second, often referred to as IOPS, than what the Cloud provides, there are other ways to achieve this, based on your data in use cases. You could think about distributing across a cluster, and thereby scaling out your database layer, or take advantage of other database sharding techniques that can route data and requests to where they need to be. In fact, if you find that you seem to be hitting constraints with Cloud infrastructure, which is again, in theory, infinitely scalable, this is most likely due to your application architecture not being built in a scalable manner.
So, think of these not as constraints at all, but merely fantastic opportunities to break these constraints by combining services and resources, which will result in improved scalability and overall performance of your system. It will also help to build an application architecture poised to get maximum benefit from the Cloud's elastic nature. So, bottom line, fear no constraints, because really there aren't any. The apparent constraints are really just differences between scalable elastic architectures and more rigid fixed ones.
Beyond letting go of perceived constraints and working to internalize these scalability and elasticity concepts and options, with the Cloud also comes a change in the role of the traditional administrator. The next section talks about how the role of administration changes when working with Cloud-based systems.
- The benefits of cloud architecture
- Core cloud-based architectural principles
- Monitoring resources and applications with CloudWatch
- Using Amazon Machine Image (AMI)
- Using Elastic Beanstalk
- Implementing message queues, Simple Workflow Service, and Simple Notification Services
- Setting up security groups
- Launching and connecting to an EC2 instance
- Elastic Load Balancing
- Virtual Private Cloud (VPC)
- Using the AWS SDK