Application Development and Operations Under One Roof

I have always seen a huge disconnect between development and operations when it comes to building and deploying applications. It’s typical for an application to be built on a single development server and to be handed off to operations to be deployed on a distributed Cloud system with numerous servers, load balancers and Cloud storage.

 

Operations are then expected to hack things together to make the application run on a distributed Cloud system. There is usually no time to go back to development to redesign the application to take full advantage of Cloud infrastructures. The result is that applications are deployed as is and scalability and high availability is either compromised or nonexistent.

 

What to discuss and address early on:

  • How will shared storage be handled and will the application work with S3 like storage (NFS and similar are a poor fit for the Cloud)
  • How will user sessions be handled in a Load Balanced environment (e.g. Database or Memcached)
  • Will the application work with Autoscaling (need logic to drain sessions upon scale down events)
  • Does the application have the capacity to take advantage of “read only” database slaves, “database sharding” or NoSQL databases
  • Do you use any software that doesn’t have a Cloud licensing model (this could get expensive)
  • Cloud servers are transient and often have ephemeral storage this means they need to be disposable and quickly recreated (applications can’t rely on the same servers always being there and persistent local storage)
  • Server IPs are often subject to change and application can’t be dependent on fixed IPs
  • Installation and configuration of the application needs to be scriptable (say goodbye to any GUI installers)
  • All application components need to be horizontally scalable (SOA and  Queue based architectures work great for this)
  • All application components have to handle failures of alike components without losing sessions and cache (central cache and sessions may be needed)

 

I think many of these get missed, because operations and development don’t come together in the design phase of the project, but only start interacting towards the deployment phase when its often too late. It’s ok for developers and operations to think differently and have different goals and concerns, but they need to collaborate early on and throughout the project.

 

ClearScale is able to have application developers and systems engineers work under the same roof and the culture of scalability is deeply ingrained in the company. This level of collaboration and the culture produces highly scalable and highly available applications and systems that we all desire.

 

Pavel Pragin
CTO

Posted in Application Development | Tagged , , , , | Leave a comment

Latest Amazon Outage and Designing for Failure

Folks,

I am getting really tired or people bashing the Cloud by saying things like “Amazon’s outage in third day: debate over cloud computing’s future begins”. People need to understand that the Cloud is not some magical place you put your applications in to and never have to worry ever again. There are always a bunch of servers in racks somewhere or some power lines going to the DC and there is always a driver that can run in to a power-line pole.

You can’t just put all responsibility in to Amazon’s hands to keep your application online. All they do is provide flexible computing resources on demand in different regions and availability zones and provide 99.95% SLA at the most for their services.

Its your responsibility to design applications and systems architectures for failure, building in redundancy mostly at the application layer.

Here are some things you can do design for failure on Amazon:
1. Use Multiples Availability Zones
2. Use Multiple Regions
3. Use database replication across Availability Zones or Regions (MySQL or NoSQL)
4. Have multiple servers on all tiers and spread them across Availability Zones
5. Perform onsite and offsite backups
6. Have a DR plan and an ability to launch on a different Cloud

These are just a few. The point is you need to design your applications and systems architectures for HA in the Cloud and not assume just because you are running in the Cloud you are protected.

Cheers

Posted in AWS | Tagged | Leave a comment

The Art of Capacity Planning


I just got through reading “The Art of Capacity Planning” by John Allspaw. He is one of the guys that designs and maintains systems for Flickr. This is someone who designed geographically dispersed systems and faced real capacity problems at Flickr. Just to give you an idea; Flickr gets 4 billion database queries per day, stores over 500 million images, and has over 20 million users word wide.  All this experience makes for a great book for anyone who wants to start doing any kind of intelligent capacity planning. It provides a good methodology and work-flow for end-to-end capacity planning with many real life examples. The book also underlines the importance of capacity planning for the cloud which is often ignored.

Here are some of the topics the book covers:

  • The difference between performance and capacity
  • Determining system requirements and setting goals for capacity
  • How architecture design effects capacity planning and management
  • Vertical and Horizontal scaling
  • Importance of measuring and recording systems performance stats on all levels
  • Different capacity tracking tools like Munin, Ganglia and others
  • Application level monitoring
  • Finding ceilings for different resources like I/O , CPU, web request and others
  • Database capacity planning and scaling
  • Predicting resource usage trends based on historical data
  • Fitting curves to determine usage trends for different resources
  • Automated forecasting using tools like Fityk
  • Procurement process and purchase justification
  • Importance of automated deployment systems
  • Virtualization and Cloud Computing
  • Cloud Computing case studies
  • Dealing with Instantaneous Growth

This book is highly recommended and is a quick read.

by info@clearscale.net

Posted in Books and Articles | Tagged | Leave a comment

Amazon CloudFront


I have been setting up CloudFront CDN to serve static content for client’s websites. CloudFront is a CDN service provided by Amazon and is very easy to setup. Most CDN providers like Akamai, Limelight and Edgecast require you to sign a contract, but CloudFront is pay as you go. In order to use CloudFront  you need to create a “distribution”, which is on basic terms an association of a S3 bucket containing your static files to an Amazon generated domain name like “d12rt92h42a9rz.cloudfront.net”. After you create a “distribution” you will get an Amazon generated domain name, add it as an alias to a CNAME and you are all set.

More about CloudFront:

  • Provides two delivery methods one for video streaming and one for basic file downloads
  • Has ability to write access logs to S3
  • Has ability to mask the Amazon generated domain name with your CNAME
  • Has numerous edge locations in US, Europe and Asia
  • Has HTTPS capability

Here is more info on CloudFront:

http://awsdocs.s3.amazonaws.com/CF/latest/cf-gsg.pdf

by info@clearscale.net

Posted in Cloud Computing | Tagged | Leave a comment

Cloud Application Architectures


I just finished reading “Cloud Application Architectures” by George Reese. I think it’s good reading for folks that are just getting into cloud computing, but are somewhat technically savvy around systems engineering. The book is focused on AWS, as its the prevalent and most feature rich public cloud out there. It’s a good primer for folks getting started with AWS and has some cool AWS command line tool examples and goes over some of the AWS services and concepts. The book addresses such topics as cloud basics, security, disaster recovery,  architecture design, databases, scalability, considerations before moving to the cloud, and more. Overall this book is good for getting you to think cloud and how same rules don’t always apply. An easy reading book I recommend!

by info@clearscale.net

Posted in Books and Articles | Tagged | Leave a comment

Amazon RDS is pretty cool!


I was playing around with Amazon RDS today. It’s a web service that makes it easy to set up, operate, and scale a relational database in the cloud. In other words Amazon manages MySQL on the server level and you can connect to it via your application or a MySQL command line. You are also able to perform various database administration tasks via an Amazon API or using something like a RightScale management platform. Here are some of the cool things Amazon let’s you do via a single API call:

  • Create a new MySQL instance and specify such parameters as (instance size, storage volume size, admin user/password, availability zone and many others)
  • Deploy a MySQL instance into two availability zones which essentially gives you two servers in diff data centers that are kept in sync, if one of them fails automatic fail-over is performed
  • Vertical scaling of instances with no downtime (cpu, ram, storage)
  • Automatic and configurable database snapshots and point in time recovery (you can start up a new MySQL instance from a backup in minutes)
  • Replication slaves can be created from a master and be used as read only slaves
  • Options typically set in my.cnf are configurable using “Parameter Groups”
  • Configure access to MySQL instances via “Security Groups”
  • Monitor MySQL logs and events via “RDS Events”

The coolest thing is how fast all these operations can be done, most of them take 5-10 minutes. Creating a MySQL slave in 5 min or scaling a server vertically with no downtime? You can’t beat that! Amazon automated all the the fancy footwork that is required to perform these operations. I have not done any benchmarking yet, this is coming next!

Amazon RDS Guide:

http://awsdocs.s3.amazonaws.com/RDS/latest/rds-ug.pdf

by info@clearscale.net

Posted in Cloud Computing | Tagged | Leave a comment