Table of Contents for

Programming for PaaS

PaaS is, by its nature, a very managed environment. You do not have to worry about scaling. You do not have to worry about the operations behind your application. You just know that you need to have it scale up or scale out; the major decisions are whether the app needs more RAM capacity or more instances. That will come to be what you expect out of your core services like MySQL and MongoDB as well. In fact, much of the time, core services can end up being just as difficult to run, scale, and manage as your applications, if not more so. That’s because, if you are managing core services on your own, every service that you add can also add a huge amount of operational complexity.

When you consider hosting and managing a MySQL service, also consider how much time you’ll spend managing it, monitoring it, and dealing with outages. Once you’ve worked with enormous data stores and terabytes of data, it becomes very clear that it’s just as technically challenging to work with services like MySQL, PostgreSQL, MongoDB, and memcached in a distributed fashion as it is to work with your application code directly.

In a non-PaaS environment, you would have to set up MySQL. Then you’d have to tune it. You would have to set up your RAID disk backend for redundancy. Then you would have to devise external backup plans. You would have to set up master-slave replication, or sometimes even master-master replication with slaves. Then you would have to add heartbeat monitors to ensure that the system is continuously watching for outages and can deal with them. You have to be tuning, monitoring, and maintaining these core services all the time. You have to look for all sorts of very low-level network settings and make sure that you are constantly maintaining, managing, and dealing with security patches and upgrades.

In a PaaS environment, a large chunk of these maintenance tasks are done for you automatically. Obviously, the quality of the operational excellence can range tremendously depending on what PaaS vendor you choose. So, evaluating the core services provided by each PaaS provider can at times be just as important as evaluating any other feature.

The end of this chapter has a checklist of questions you should have good answers to before committing to any vendor. It is critical you take these into consideration early in the decision-making process.

Look for what kinds of limitations you will run into:

When considering a PaaS provider, having this information ahead of time is important as it tells you whether or not you are going to be able to scale your application.

Keep in mind that with many applications you are never going to hit data barriers. Most applications do not need terabytes of disk. Most don’t even need gigabytes. Generally, most applications need just tens of megabytes, with room to grow into the hundreds of megabytes.

So, you should be looking for and predicting how much data you are going to need to store in MongoDB, PostgreSQL, CouchDB, Redis, or memcached. You’re trying to understand, “Does my PaaS allow me to grow? Or will it limit me and make it hard for me to move off?” You’ll need to put in a little work up front talking and thinking about what your application is going to require at the higher end.

Some PaaS providers are going to be a lot better at this than others. But much of the time a PaaS platform will have already tuned the database, the configuration files, and the network interfaces so that they are significantly better than out of the box. It will have done a lot of thinking about failover and redundancy, which can be difficult problems to solve, especially if you are just a developer. Even operations teams can easily spend weeks or months planning and building out the procedures to do things that come right out of the box in a PaaS-managed service.

The benefits of using a PaaS for core services can be significant. You get up to speed much faster. You get to prototype faster. You get to write more code sooner. You don’t have to worry about how to do a distributed memcached or master-master MySQL. You don’t have to figure out how to get through SMTP filters for mail servers and through the spam filters at Google and Hotmail for sending email. PaaS can take much of the burden off your shoulders. A PaaS provider, giving you greater flexibility and speed, can do all of these things for you.

When you are trying to set up managed services on your own, the ones that can provide the biggest headaches are databases. Managing them and backing them up can take more time than writing the code for your application in the first place. The advantages of working with managed SQL core services in PaaS can be significant if you do your homework and make the right choices.

Typically, caches end up being stateless and volatile. There are a few popular caching technologies, some open source like memcached and Ehcache and some proprietary ones like TerraCotta for Java. They do not require as much overhead as a SQL or even a NoSQL database. It is easier to scale them and to run them. If they die it is not going to cause major problems, as long as there is redundancy in place.

The advantages of working with caches in PaaS actually outweigh some of the disadvantages of working with databases in PaaS, since often the hardest part of implementing caches is setting up redundancy, which is typically handled for you within a PaaS environment. Again, checking with your PaaS provider to ensure that there are redundancy and failover mechanisms in place is an important bit of research that needs to be done.

The only other consideration is the limit on how much data is cached. Sometimes a PaaS provider limits you to only being able to cache a certain amount of data. Often that will be sufficient, since most caching systems will purge the oldest (least recently used) data automatically, ending up with only the most important data in memory. However, if your dataset grows past the limit and you are constantly hitting your SQL or NoSQL backends, and your PaaS provider can’t give you a higher limit, it’s time to move to hosting the cache yourself.

Moving from a PaaS hosted cache to a self-managed caching system is not usually a very hard process since caches by nature are volatile, so it is not so important to set up a managed cache for yourself before you hit your limits.

Sending email in a cloud environment can be a very difficult proposition. When you are using virtual machines in Amazon Web Services, Rackspace, or Azure, they often have IP addresses that have been blocked by email providers. Big email providers like AOL and Gmail will block large groups of IP addresses owned by public cloud providers because spammers have regularly taken advantage of them in the past.

When using the public cloud, it is very likely that your application is going to run on an IP address that has been blacklisted by email providers, which leads to a question: how do you send email to your users within a PaaS public cloud environment? Also important for some applications is this associated question: how do you accept and process inbound email in your application?

If you are running a blog, this may not matter. But if you are running an interactive service and part of the service has to do with processing email, you’ll be facing a unique set of challenges when using the public cloud.

The smartest approach is to leverage a managed email service. Often this service is going to be different than your database or caching service. It is likely not to be natively hosted with your PaaS provider. It is usually an independently run software service, and generally it will charge by how many emails you need to send. Sometimes your PaaS provider can facilitate the connection between your application and the email service by setting up an account for you. These kinds of services will send email for you, either one-off or in bulk. A key advantage is that the emails sent from these accounts have already been whitelisted by Gmail, AOL, and Hotmail, which means they are much more likely to get to your users’ inboxes instead of being blocked by spam filters than if you sent them directly yourself.

You may not realize it, but being whitelisted and remaining whitelisted is actually a full-time job of its own. It is very difficult to keep up to date with the requirements that Google, AOL, Microsoft, and Yahoo! impose. Making sure that most users keep receiving communications is easy to do when you are only sending a few dozen emails a day, but it becomes incredibly difficult when you are sending hundreds or thousands a day. In the end, it just makes sense to leverage these services. You can go through third parties, but they may also be managed by your PaaS provider or by your IaaS provider.

Here is a list of a few popular mail services:

Whether you are running your own infrastructure or building on PaaS, there is one challenge that is the same: monitoring all the pieces of your application.

This means knowing how much load your application has (right now and historically), and how your database is doing (in terms of transactions, disk I/O, memory, etc.). It also means understanding how many people are getting data concurrently (or trying to) and whether your service is succeeding or failing to serve them.

One of the most important parts of dealing with managed services is understanding the limitations of scale. To find those limits, you need to do performance tracking and load testing.

In many PaaS environments, there are add-ons and sometimes even native services that will do this for you. These services can test everything that we’ve discussed in this chapter—the monitor, database capacity, concurrence, limitations, and latencies—so that you can see how your application will perform when 1,000 people come to your site.

These kinds of services should be utilized after you’ve set up every other kind of managed service, then tied into your code. You can use them in different levels. You can see what it is like when 10, 10,000, or 100,000+ concurrent people are hitting your site so you can test your capacity planning. You can run fire drills to scale up both the instances of your application and also your database capacities to make sure that your team is ready to react proactively when your application is under siege.

Summing it up: performance and load-testing services are critical for working through many of the scaling use cases that we have been alluding to.

Here are a couple of popular load-testing services:

A final but very important consideration was touched on earlier in this chapter: you must plan ahead.

You need to think about how you can upgrade when you hit the limits. There are two clear choices:

How you proceed will depend on what PaaS you select, how it manages its systems, and how much access you get to those systems. There are PaaS providers that will let you upgrade seamlessly and allow you to up your resources, consumption, and concurrency with no change at all.

However, you should be aware that there are some providers that will require you to pick a new plan with a new data size, while they create a separate data storage container for you with higher limits. That new data storage will be bigger and have more capacity, but you are going to have to move your data and change your code. Sometimes the PaaS will do that for you, but that takes time. During the changeover, you are going to need downtime to migrate into the larger-capacity plan.

This process will be similar if you are going to move from a managed service to a non-managed one in which you do the management. If you need to create your own database to handle more capacity than the PaaS permits, you will have to set that up as a separate container and figure out a path similar to the one we just described in which you take your site down while you move the data over to the new database with the larger capacity.