4 Reasons PaaS is Perfect For Your Startup

Get your Startup going like a Mustang on a PaaS

Time to tell a little tale, a fable, an illustrative example, a scenario you might find yourself facing. You and your friends work for a large enterprise company, or you just graduated from college, or you are bored with your high school classes and you are hanging around a camp fire at a national park and you figure out the next KILLER social media application. People are going to want to check in, share pictures, and share over the web their checkins at national parks - ParkWithFriends. Your friends include a couple of server developers, a graphic designer, a mobile developer, and someone good at talking to business people - the team is all here.

Breaking the Cycle of Pain

At this point, a lot of potential startups start to hit the wall around server hosting, configuration, and price. First, where are you going to host your application; second, if you find a place to host your application, will they be around and supported while your application grows; third, will they let your "hardware" (and therefore budget) start small and easily grow; fourth, will they give you an easy way to rapidly iterate different designs or architectures; fifth, are you going to need to hire a sysadmin to configure and maintain your app server and databases; and finally, can you build on their platform without being locked-in if you want to use different hosting in the future?

It turns out that Platform as a Service (PaaS) can solve a lot of these dilemmas and, shocker coming from me but, I think OpenShift excels as a solution. By moving your development into a hosted cloud solution, especially one that is open source with a free hosted tier, you can avoid many of these typical server infrastructre pain points. In the rest of this post I am going to talk about all the ways you can use OpenShift, or a lot of the other PaaS solutions, to launch your startup with less cost, more reliability, more flexibility, and quicker product iteration.

Costs Less

With a generous free tier, OpenShift gives you a great way to start building a working application rather than slideware or some limited service. Most other hosted PaaS platforms also offer some sort of trial or introductory tier. This basically gives you free servers to begin creating your application. With a polyglot PaaS (one that supports multiple programming languages) you can also try out different languages or combine them depending on the needs of your application. This goes beyond getting an AWS Micro instance, here you get all the OS installed along with the application servers and database instances. All of the bits of these pieces are kept up to date by the PaaS operations team.

Speaking of an operations team - usually when your project is just starting out, you don't have enough infrastructure to need a full ops team. In addition, in the early stage, your application is not complicated enough to really need an operations team. The usual course of affairs is that you take away valuable development time to focus on setting up, configuring, and maintaining server infrastructure. While using EC2 lessens the need to rack or stack physical servers, you still need to pick an AMI, configure the network, configure the server software, and maintain the OS and server software. So either you are using your startup funds to hire a sysadmin or you are cutting into your coding time. With a PaaS you get all of the basic sysadmin features (and then some) right out of the box. OpenShift handles everything required to run your service except for writing the code - we do the OS, network, and server work for you. This is a huge savings in time and money that often goes unaccounted for since some developer usually just sucks it up.

Platform Reliability and Security

Since our team had no sysadmins in it, as I mentioned above, it would have been configured and maintained by developers. What this means in practice is that it is unlikely that anyone on the team would care or check enough for system updates, creating redundancy, watching to see if the network was up. With a PaaS, the provider actually does all this work for you.

For example, on OpenShift, when you create a scalable application, behind the scenes we spin up a load balancer, enable services to monitor the amount of HTTP requests, apply SELinux and Cgroup policies, configure and start your application server, create a git repository for your code, create hooks to build and deploy your code, publish your DNS entry, and also in a state where they can spin up more capacity as needed tuned to your cost or capacity needs. Think for a minute, well OK maybe less than a minute, but think about all that sysadmin work you, or your developer has to get right. When you don't get these items right your site is down or not working properly and your service is not doing what people expect of it. Once again, you are taken away from doing your coding, partnering discussions, getting new users, or time with your family. Instead, with a service like OpenShift, you get domain experts setting up your systems in a reliable AND repeatable manner. The next application you spin up, whether for a new service in this application or for another application, will have all this work done for you again. You don't have to go back to the notes you wrote 3 months ago and try to remember all the steps you used.

Finally, a PaaS will also apply the security updates to the platform and server software. This is done without you having to be subscribed to a mailing lists, figuring out the severity, does it apply to your version, and then how to patch the machine. In general, at OpenShift we leverage the experience from the entire Red Hat team when deciding which patches to do when. If they have a high risk rating we are more likely to roll it out immediately and to everybody, while lower risk patches may come with more lead up. But in the end, my team didn't have to be distracted with yet another task that was not our competency nor did we incur extra costs over just being on the PaaS.

Greater Architecture and Language Flexibility

One of the last big benefits of being on a PaaS, especially those platforms that are polyglot, is more flexibility in your architecture and coding. For example, with OpenShift if one of your web service developers really knows Python well but another really likes Java - no problem. Both languages are available, actually we offer Python, Java, PHP, Ruby, Node.JS, and Perl as programming languages. The Python developer doesn't have to learn Java and vice versa - you can have each of them work on a separate service. You might say, "well we should all write in the same language for uniformity". In a non-startup or larger project I would agree with you, but in a startup your main barriers are time to implementation and rapid iteration. Let the developers work in the language they are comfortable using and when you are big and famous you can start to homogenize your code base.

Another example might be using a NoSQL versus RDBMS data store. Your team may not have used a NoSQL data store yet but they heard they are the greatest thing since sliced bread. Rather than spending your time trying to figure out how to install, configure, and run it just so you can prototype with it, instead with a PaaS you can just spin up and instance and start to prototype. As a matter of fact, with OpenShift, you can spin it up for free, run your prototype for as long as you want, destroy the application or cartridge, and then reuse that capacity in another application.

Since the gears (OpenShift servers) can be of the same type, it also makes a good platform for testing performance between your different architecture decisions. It is easy and straight-forward to spin up the same architecture except swapping datastores or app servers (like Tomcat versus JBoss) and look at performance differences. While there might be single run differences based on the node the gears are created on, with more tests over time you can get a fairly good idea of which architecture is better for your application needs. When it is done you can just delete the gears and there will be no more charge (if you moved above the free tier).

With a PaaS you have the flexibility to create the application with the languages and data stores you already know and enjoy. Or a quick and easy way to prototype multiple solutions. You can let the different members of the team work the way they want yet easily collaborate through shared git repositories and SSH public keys. Developers can keep doing development work rather than sysadmin work. There is a team of professionals from the entire Red Hat family helping to keep everything under your code and data up to date and as secure as possible. Your team gets to focus on creating the best application possible with minimal distractions and worry.

One Caveat

I do want to add a last statement about an important consideration when choosing a PaaS - the degree of lock-in. When you build to anyone else's platform other than your own, it is important to pay attention to the degree to which you will be "forced" to stay on that platform. There are some PaaS platforms which require you to use libraries specific to their platform for your application to work. If for some reason those platforms change their pricing or terms of service in a way which you find unacceptable, you are faced with a tough decision - either spend valuable development cycles porting off the platform or accept the new costs/terms. As you might expect given my belief, OpenShift strives to avoid lock-in. We are open source so you can always host the entire platform yourself, we use standard languages and databases without the need for any special libaries, and the only tools we require to work with us is git and SSH. The only porting that would be required to move from us to another platform would be to just take the environment variables we use for database and other information and repoint them to the proper place on your new platform.

For all of these reasons, a PaaS (and I like OpenShift), is the best way for a modern startup to take on building the next big thing!

Next steps

Tags: