Professional Documents
Culture Documents
Table of Content
Welcome to the latest Kinvey eBook. We aim to help our community of developers keep pace with the latest trends in app development, tools and marketing. Typically we share our perspective on our blog, but when our audience is interested in a topic that cant be done justice in 500 words, we publish an eBook instead.
is perhaps the most fundamental of the categories. Before diving into our guide, lets rst review IaaS basics:
According to TechTarget, Infrastructure as a Service is a cloud-based provision model that services cloud storage, virtual servers and networking components to application owners for a usage-based cost. Its goal is to is to become a
This eBook curates some of the best thinking from Kinvey and outside experts on how developers should approach Infrastructure as a Service (IaaS). The eBook emphasizes Amazon Web Services (AWS) because its the best known vendor in the space, though we dont recommend one provider over another. The eBook highlights the benets of IaaS, helps in the IaaS vendor selection process, shares best practices for hosting an app on AWS, and provides tips for what to do in case of a service outage.
foundation for Platform as a Service (PaaS) and Software as a Service (SaaS) providers by providing a exible operating environment. In the IaaS environment, the service provider owns, runs and maintains the infrastructure equipment, while the consumer takes responsibility for conguration and operations of the guest operating system, software and database.
A variety of technologies can benet from IaaS: cloud-based CRM systems, web, media and mobile applications, big data systems, and much more. But, IaaS
is not right for everyone. There are some important factors to consider before determining if your application would benet from IaaS.
Choosing an IaaS provider is a big decision. You want to trust the provider with your data and, essentially, your entire application infrastructure. As with any service, there are pros and cons associated with IaaS that must be assessed before deciding whether or not to use it for your application.
you plan to expand your feature set. With an increase in features comes an increased demand on infrastructure. Scalability doesnt only apply to the number of users, sometimes features too need to scale. you dont have a clear sense of your applications storage and networking needs. Successful IaaS deployments benet from clear user up-front requirements. you are an enterprise concerned about youre an individual developer, small dev shop or startup with no existing data center infrastructure or youre an established company taking on a large project that would require signicant additional data center infrastructure or sta. rogue users. (One risk of IaaS is rogue or unwarranted commandeering of services. Because IaaS requires governance and usage monitoring, Vordel's Mark O'Neill recommends that enterprises establish cloud service governance frameworks that help prevent employees from accessing you have a low server-to-admin ratio and are looking to cut costs. information or services they are not permitted to use.)
systems).
Another way to size-up vendors is by common user concerns, which is the thrust of this second TechRepublic chart. Specically, the table assesses vendors against security features (certications and protection), ease of migration (open standards and VM upload), and reliability [service age, Service Level Agreement (SLA), and support].
This chart from TechRepublic evaluates the best-known IaaS providers against how they compare to common cloud promises. The comparison takes into account a range of factors, including pricing (variety, average, data transfer
Is IaaS really the solution you need? Depending on the complexity of your infrastructure needs, you might be better o opting for a higher layer in the stack such as a Platform as a Service (PaaS), or even Backend as a Service 5
and storage costs), scalability (scaling up and down, monitoring, and APIs), and choice / exibility (number of data center locations, number of instance
(BaaS). The advantages of choosing these alternatives are reduced operational complexity and decreased time to market. The disadvantages are reduced control and a narrower set of choices as to the underlying infrastructure components. PaaS or BaaS might be a good starting point, allowing you to focus on building the application / system until you deem it necessary to exert greater control on the choice of infrastructure components.
Plan for the worst case No system is infallible. Outages can occur, even at your cloud provider of choice. It is important that you have a plan in place to address this were it to occur. For example, you should consider osite backups for your critical data and alternate deployments from your main location.
Understand your support requirements Not all IaaS providers provide the same levels of support. In some cases, support
IaaS is not a silver bullet Some key benets of IaaS include ease in deployment, redundancy, and the ability to scale much faster than conventional means. Deploying a distributed system, especially across geographic regions, can also be achieved in more easily.
is priced independently from the actual product and may end up being quite expensive. Most providers oer a free support level via community forums. This may or may not be sucient depending on your needs.
With so many factors to consider, However, it is important to note that while IaaS gives you the means to provision, deploy and scale infrastructure, it is up to you to congure, monitor and maintain said infrastructure and use it in a manner that makes the most sense to your system. You might be able to build multiple redundancies into a complex system sitting across geographic regions in a matter of hours, but if your rewall rules are improperly congured, youre still vulnerable to attack. selecting an IaaS vendor for your app is arguably the most dicult part of the process. The next step is actually deploying your app on the chosen IaaS provider. Because AWS is the most popular vendor it will be the main focus moving forward.
without using capital expenditure. Within AWS are several infrastructure building blocks, including EC2, S3, and RDS, to name a few. Click here for a full list of AWS products for mobile application hosting.
Start small
Start by moving a small project to AWS before your full project is underway. This way you can fully test and learn
AWS may be a compelling choice for your apps infrastructure needs, but remember, if you want more than just hosting, there are other categories of *aaS vendors, such as Platform as a Service, Software as a Service, and Backend as a Service, that address dierent application needs. You may want to consider vendors in adjacent service categories as well. That said, below is a list of best practices for hosting an app on AWS.
about the various components that youll be using without worrying about managing an entire project.
Start free. Consider starting with Amazons free tier to test and become familiar with the
Know what your project/appliccation is and the problem it solves before you dig in.
platform before jumping into a full development eort. You get 5GB of storage free for a year on S3, so you can easily back something up for free to see if AWS is the way to go.
for high availability and disaster recovery. Ensure your design anticipates and manages component failure to signicantly reduce the chances of it failing.
unforeseen outages due to factors out of our control. If it wasnt AWS, it would be the other cloud provider you chose. But there is still hope: when AWS is down, you can still be up if you take the proper measures to prepare for possible outages in advance.
outages The eastern region of the US is the most likely area to suer outages because ...
it has the oldest data centers. it is the largest in terms of data center footprint. it is the default region for most customers, who dont bother changing it
because its cheaper and/or they arent aware they can change the region.
Amazon provides a rich set of APIs that allow users to access the control plane for various infrastructure components.
In fact, a judicious use of these APIs via client libraries and scripts is what allows one to be able to do things like launch new instances based on trac volume and / or provision new infrastructure as necessary. When an outage occurs, aected customers attempt to remediate their situation by trying to provision new servers in other availability zones and / or regions in order to redirect web trac and/or proceed with other tasks. 9
SURVIVAL KIT
AWS
10
In this segment, well explain how to fully prepare for an AWS EC2 outage with a node.js and MongoDB stack. Node+Mongo on EC2 is a very popular software stack among web services developers. There are many user guides on how to design this system with built-in redundancy so that even coordinated failures dont bring down the service. The absolute minimum for a resilient service requires a MongoDB replica set behind a load-balanced node farm.
MongoDB instances should each be load balanced across multiple Availability Zones. The more the better.
4. Place the node servers and the mongo servers all in a security group, which allows only the Mongo ports internally and your application ports externally. This is trivial to set up and protects your database from external requests.
You are not ready for an EC2 outage until you have deliberately shut down components in your system and veried the expected behavior. As you periodically do this, you might discover that there are gaps you did not account for. Take the following steps to be as prepared as possible:
model has limited robustness, but having authentication in your MongoDB store is still useful even if the application and the database are inside an EC2 security group. For your data to get exposed, you will have to make multiple mistakes at the same time, which happens, but the chances are greatly reduced.
1. A Node.js single event will by default crash on an unhandled exception. Use upstart or forever to restart the process. 6. Ensure that failover happens smoothly. Shutdown the primary Mongo instance and see what happens as requests keep 2. Use Monit, an external process on your server that makes liveness checks and potentially restarts your service. Monit will also email you if and when it had to restart. While upstart ensures that your process is up, monit ensures that it is responsive. 7. What this error message means is that the failover happened, but your 3. Your application instances and your 11 applications request is not authenticatcoming in. The replicas notice the down primary and one of them takes over, but upon an incoming request you see this error message: unauthorized db:mydb lock type:-1 client:127.0.0.1
ed. This is an example of an esoteric bug that may not show up until you do a full end to end test. The bug is now in a pull request. Since pull requests dont get released quickly, use npm git dependencies to install your app from your forked repo.
GoDaddy, unfortunately this guide cannot help - youll just have to wait until GoDaddy is back online. 1. To start, log into the Route 53 dashboard in the AWS Console.
8. While you have a down MongoDB instance, it may take a long time for your application to restart. The default in node-mongodb-native is no timeout, which means leaving it down to the OS. To avoid yet another timeout cycle, use Mongos connectTimeoutMS setting.
...know how your application fails when a network service like DNS is unavailable
9. This ensures that your restarts will take a little over 500ms, if you have a down instance. However, dont assume that your Mongo SDK supports it node-mongodb-native doesnt, unless you use this github patch.
2. As the landing page describes, your rst step is to create a hosted zone. A hosted zone is a concept created by Amazon to describe a collection of DNS records (i.e. A records, CNAME records, MX records) that are managed together under a single parent domain name. You
10. You are now prepared for an AWS outage. Bring it on.
can use the Route 53 dashboard to manage these hosted zones. For a good explanation of the dierent types of DNS records, check out Googles guide.
3. Click Create Hosted Zone, and ll in your domain name in the form that appears on the right.
4. When you created the hosted zone for your domain, Route 53 lled in some basic DNS records. To see them, select
DEVELOPERS GUIDE TO AMAZON WEB SERVICES your domain name from the list, and click Go to Record Sets in the top right. Youll see that Route 53 populated your domain with a set of NS records and SOA records. with your application. If your app relies on DNS to connect to another server (i.e. database), it may stop trying after a few failed lookups. At this point things probably require manual intervention, even if the DNS service recovers. The key 5. Your current site may have extra DNS records needed. For example, if you host a blog on Tumblr, you probably have a CNAME record setup to create that link. Also, if you receive email at your domain, you probably have an MX record set for that. Make a list of all these extra records youll need, and add them now (use the Create Record Set button). To prevent manual intervention, you can use a tool called Monit. Monit is a daemon that is responsible for monitor6. Finally, its time to make the switch. Head over to your current registar, and change the nameservers from the GoDaddy addresses to the ones provided in the NS record set on your Route 53 dashboard. Note: because DNS servers around the world cache this value, it may take some time to see the change work while the update propagates through the DNS system. Lets take a look at a basic cong to start: ing your server and application health. It can also be congured to check the health of external services such as DNS. takeaway from this is that you should know how your application fails when a network service like DNS is unavailable. And you should know whether or not it will require manual intervention to recover.
that listens on 127.0.0.1 on port 9009. When there is a failure, Monit alerts you and attempts to restart the process. We dont want to constantly restart the service if it is unhealthy, so if the app fails 10 times within 10 cycles, then Monit will leave the app o and stop 13
monitoring it.
When a network service fails like DNS, your application becomes unhealthy, tries to restart 10 times, and then becomes unmonitored. Now youre at a point where things require manual intervention to recover, even if DNS becomes available. Lets congure Monit to take care of everything for us.
DNS is healthy.
You should now be able to recover your app during a DNS failure. To be 100% sure this works as intended, we can simulate another DNS outage using iptables.
Run this command: sudo iptables -A Building on our previous conguration: OUTPUT -p udp dport 53 -j DROP This command will prevent any DNS queries from completing. If your app relies on DNS you should see it fail once its DNS cache has expired. This should trigger the DNS check to be enabled via Monit. You can check the status of Monit - Were still monitoring our HTTP app on port 9009 - When the application fails now, it kicks o the aws-dns-healthcheck monitor. - The aws-dns-healthcheck monitor checks to see if it can resolve DNS on 172.16.0.23 (the default AWS DNS server). - When DNS reports healthy for 3 cycles, monit execs a script to try to recover the app. Your application should now try to recover after the DNS check returns to a healthy state. The examples above focus on how to approach a failure in the DNS service. In reality there could be a myriad of The example recovery script is simple: external services that may aect the health of your app. You can use the same approach as described above and It calls /usr/bin/monit start appsrv1 which will attempt to start the app and 14 expand the aws-dns-healthcheck into a generic health check for your applicaTo re-enable DNS run this: sudo iptables -F monitoring using the command: sudo monit status
tion. This could include testing network connectivity, connectivity to external services (e.g: a database), and any other processes that your app depends on. You can nd examples for monitoring all kinds of services on the Monit website here.
Again, the takeaway from this is to know how your application behaves under dierent failure scenarios. Testing connectivity loss, loss of network services, and other failures are very important when building a high availability application.
15
Written by
Kelly Rice and Shubhang Mani
Designed by
Jake McKibben
Written by
Kelly Rice and Shubhang Mani
Designed by
Jake McKibben