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 four 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.
- You can read “Engineering High Performance Applications with AWS – Part 4” by clicking here
- You can read “Engineering High Performance Applications with AWS – Part 5” by clicking here.
Choosing the right Performance Engineering Strategy – Doesn’t matter if you are using an agile development approach, the traditional waterfall model or custom development approach that’s a mix of both, you will have to work out a strategy for tuning, optimization and delivery of the overall system such that all your Non Functional Requirements are met. It’s generally a good idea to review the overall approach for Engineering Performance with other experienced Performance Engineers within the organization and make sure you are on the right path. A journey well begun they say is a journey half complete.
Whatever approach you consider taking your efforts will be split between tuning of the application and tuning of the AWS components. AWS tuning is an art and you will pick up the nuances of AWS performance optimization as you experience the various bottlenecks through iterative performance testing, identifying areas of the AWS solution that need to be scaled up in terms of compute/storage power. As part of AWS tuning you are focusing on delivering a platform that has the grunt required to deliver the performance and scalability as documented in your Non Functional Requirements. You platform also has to also have the ability to scale to the peak workload and to be able to do that you need to be able to leverage the underlying capability of AWS auto scale towards ensuring seamless delivery of services while meeting the performance / scalability requirements.
In addition to tuning the underlying AWS platform you will also focus on tuning of the application that resides on the AWS platform and things are not necessarily very straightforward here. Tuning applications, middleware, databases, etc. require the right set of tools, capability, experience and more importantly insight into making them perform / scale. Performance tuning and optimization is an iterative process and based on the outcome of your performance tests you are able to make decisions on aspects of the application or underlying AWS infrastructure that needs tuning or optimization.
With AWS benchmarking is a must – It’s not to say that you can get away without benchmarking a system if you aren’t using AWS. When using AWS compute infrastructure, benchmarking your system is highly important since there is a definite need to confirm if the underlying cloud compute power you have chosen is able to sustain your peak application workload. Even if you’ have benchmarked the similar applications on different cloud compute systems it’s important to benchmark your applications on the production equivalent infrastructure to ensure that the cloud compute power you have chosen is able to deliver the expected performance and scalability for the documented Non Functional Requirements.
The difference between 6 small, 3 large or 1 extra-large can be significant both in performance but also in costs especially since you are using cloud compute infrastructure. We would also recommend that you try to think in terms of cost and performance throughout your project. There will be times when you might need to consider performance over cost and at other times you might need to consider cost over performance depending on the business or customer need being addressed.
To improve performance you need to first understand what performance is – Before you begin addressing performance you need to understand what performance is in first place. And to understand what performance currently is looking like you will need to harness the power of relevant tools to capture performance metrics from across the application, middleware, databases, infrastructure, networks and storage. Hopefully your IT organization has some of the best of breed APM (Application Performance Monitoring) tools available but if it does not there’s little to fret since there are quite a few open source frameworks out there that can do a similar job for a fraction of the cost.
If you have the funding available internally you will have the opportunity to dump the legacy monitoring tools in favour of the Next Generation APM toolsets currently available as SaaS and on-premise options. It’s however not possible for us to recommend a particular set of APM tools particularly since the choice of APM tools depends so much on the nature of the application, the underlying infrastructure, the insight you desire and the deployment options you have in mind. Some of the options that come to mind are:
We would also recommend that you invest sometime on the following industry APM groups:
When choosing a particular toolset please keep in mind your internal organization skillsets and production needs in addition to the factors mentioned above. With regards to Monitoring or APM tools you might very well consider different APM tools for development and production depending on what you wannt to get out of each of the phases and accompanying toolsets. In development, ideally you would need more technical, invasive and expensive tools which would be used in specific situations to debug, tune and tweak the application. However production tools need to be more intuitive, less invasive, and adaptable because they are running all the time, even when no one is looking. Production tools tend to be more lightweight and have to able to spot anomalies using different heuristic algorithms. Out point of view is that a good old “KPI based” Monitoring is no longer good enough, especially when using Cloud based infrastructure to deploy your production applications.
Summary – If you are a Performance Engineering lead and your organization has decided to take the plunge into using AWS there are quite a few challenges that will come your way. The best way for you to deal with these challenges is for you to start experimenting with the platform, understand it’s various nuances and get to grips with the challenges tuning and optimizing AWS to meet your performance and scalability requirements.
We hope you thoroughly enjoyed this series on Amazon AWS as much as we enjoyed putting it together. We sincerely hope that this series on AWS has given you and your PE organization the much needed shot in the arm to go out there and start experimenting with the AWS platform. AWS has a lot to offer in terms of scalability, flexibility, cost of operations, etc. but with all that good also comes the challenges of sharing virtual resources, not knowing whom you are sharing the platforms with, not having a performance SLA for your infrastructure and having the need to build HA, Failover including factoring in the need to manage performance degradation as part of the design.
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). During this period, he has played various roles in the Performance Engineering (PE) with extremely high focus on Application and Database Performance. He has served as Performance Doctor (fixing unhealthy systems) , Performance Fireman (triage of production fires) , Performance Paramedic (putting the system together by applying field triage, duct tape, whatever data, domain knowledge, best guess, wishful thinking or folk-lore available to fix a problem) and Performance Plumber (removing blockages and searching for leaks). He 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.