This series of articles focuses on the basic concepts and gotchas around building high performance applications using Amazon’s AWS platform. Dmitry Agranat explores the foundation principles of AWS while gradually introducing the reader to various important fundamental concepts around AWS/EC2. Dmitry hopes that through this series of articles, you as the Performance Engineer would gain enough of background knowledge on Amazon’s Cloud capability to become an effective contributor when it comes to engaging in AWS related discussions/projects within your organization. These articles essentially are aimed at helping readers build stronger understanding of AWS/EC2 and eventually greater appreciation for what Amazon’s AWS has to offer.
If you are still unsure about the various Amazon Cloud Computing Infrastructure blocks and the basic concepts around Amazon’s Cloud Computing Infrastructure we would highly recommend that you go read up the previous two articles in this series. Links to each of two articles are provided below –
- You can read “Engineering High Performance Applications with AWS – Part 1” by clicking here.
- You can read “Engineering High Performance Applications with AWS – Part 2” by clicking here.
- You can read “Engineering High Performance Applications with AWS – Part 3” by clicking here.
What is the cloud hype all about – Over the last decade there has been tremendous hype generated using the word “cloud”. Almost every vendor’s offering these days has some service or software extension that is cloud aware. By leveraging the word “cloud” and rebadging their services as being “cloud aware” vendors have built onto the existing hype and created good amount of confusion out there. So lets be very specific what we mean when we refer to the word “cloud”. Cloud for all intents and purposes within the context of this series of articles on AWS is essentially about –
- Computing Power
Benefit of using the cloud – Thanks to all of the hype created by vendors around the concept of the “cloud” we now thoroughly understand the benefits of an integrated cloud approach within organizations. Cloud offers organizations large and small the ability to leverage publicly available computing power and storage required to host their applications just by the swipe of a card without having to spend large amount of lead time procuring hardware. The cloud much like the internet has extended the level playing field allowing organizations to scale up and down the infrastructure resources they need on demand without having to invest in physical assets and have those assets depreciate on their books. Amazon’s cloud offering enables organizations to try concepts out and scale application platforms out at minimal cost with minimal effort.
Challenges When Using The Cloud To Deliver Systems – From a Performance Engineering standpoint using cloud services or cloud infrastructure has many implications on the overall application design. There are numerous technical and non technical factors which have the potential to impact your ability to meet the overall Non Functional Requirements. However most of the vendor SLA’s (or the lack of it) are hidden in detailed EULA, Product Manuals and Documentation Wiki’s which most of (including me) tend to skim rather than read in detail. There is a huge downside to using the cloud, something that you really need to be well aware of and we will dig into the detail in the following paragraphs.
Leveraging cloud infrastructure (compute or storage in this case) requires you as the Performance Engineer to think significantly differently than when you are using traditional on premise infrastructure. Here are some of the reasons why –
- Most cloud service providers do not provide end to end SLA’s. Any SLA’s they sign up to are limited to the confines of their data centers
- Most cloud service providers do not provide performance sla’s for their own infrastructuMost cloud service providers require the application architects to designre
- Most cloud service providers require the application architects to design for scenarios where performance degradation could impact end user experience
- Most cloud service providers require the application architects to design for scalability where a sign of performance degradation requires the underlying platform to spin up additional instances
The above list of scenarios isn’t meant to be exhaustive in anyway but is intended to help you understand that the onus on building applications that scale, perform and are highly reliable is purely on the application architects and developers. The big difference between on premise applications and applications built for the cloud is that application architects, designers and developers have to build the platform ground up to perform while handing failover and performance degradation scenarios as part of the design.
Lack of detailed visibility – While working with on premise platforms, you as Performance Engineer has the ability to examine all aspect of the hardware that has been instrumented and monitor the application, operating system, network and storage from a performance and availability standpoint. When you host your applications on AWS you do have access to the application and operating system performance however detailed performance metrics regarding the underlying virtualization system (hardware) is nearly impossible to know. In addition, think of AWS as one big shared storage where you, as an existing customer, will be competing with others on shared resources. And if someone happens to run a Stress Test, they will definitely be stealing your resources and as a result you can expect your performance to degrade.
Closing notes – To add more fuel to the fire, the concept of Elasticity and auto-scaling guarantees resource capacity, not performance. That would probably come as a surprise to you but it’s true. Building applications for the cloud is interesting but can also be challenging as we’ve mentioned above. We can go on with above examples and even put here several links which might scare the hell out of you (we aren’t trying to convince you to buy some magic tool which mitigates these issues), there isn’t need for one. There are several known and widely acceptable ways to mitigate each issue, the most important thing for you to remember is how to detect issues, why they occur and how to resolve them. We recommend that you start by reading the following document Please Click here.
Amazon, AWS, S3, EBS, EC2 and Cloudwatch are copyrights owned by Amazon US (www.amazon.com).
Dmitry Agranat (LinkedIn), is a Performance Engineering Principal with primary focus on bringing a positive impact on overall organizational system performance. His professional career has started in 2005 at Mercury (now HP Software). Dmitry has worked with many internal and external customers to both solve immediate performance problems as well as to educate on building solid organizational performance management methodology. Dmitry believes that Performance Engineering (PE) is still not well understood, agreed upon, unified or can be quantified, thus requires building solid and effective entrepreneurship around Performance domain.