Five Ways PaaS will Rock the Enterprise
Platform-as-a-Service is one of the hottest new technologies to hit the market in recent years. Already it has seen significant adoption from startups and web 2.0 companies using it as their development, test, and production environments on platforms such as Heroku, Engine Yard, Microsoft Azure, and AppFog. Gartner predicts that by 2015, most enterprises will have part of their run-the-business software functionally executing in the cloud, using PaaS services or technologies directly or indirectly.
Most surprising is that even with developers and web 2.0 companies creating the majority of PaaS adoption, PaaS will still become the most disruptive technology transforming business in the enterprise for the foreseeable future.
While this transformation is created by technology, it enables multiple other parts of the business to evolve: staffing and hiring development teams, enabling service/deployments/scaling, maintaining ownership of a service, enabling business teams to interact as stakeholders in the development processes and shifting operations teams to know and understand the business and how resources are handled.
Four Golden Rules of High Availability
For over the past decade I have worked in the enterprise building large, high-availability systems. As CTO of a cloud company, one thing that still surprises me is the general lack of industry understanding of what it means to the business and application to have high availability. So I felt inspired to share a few rules for enabling high availability that I follow each time I build a system. But first…
Before the rules, let’s set some quick baseline on high availability measurements and how these apply in context of businesses. You have probably heard over and over again providers promising a percentage of uptime for a service such as 99.95% or 99.999%. This is how the majority of service providers and applications show the amount of time in agiven year the service is available and working. Normally this does not include maintenance windows (where they are doing an upgrade of the service), or even things out of their control such as the connection to the service (such as internet).
Performance is a Feature… Even for IT
Recently Jeff Atwood over at coding horror wrote a great blog about how performance is a feature. I not only completely agree with him but I also wanted to point out that performance for back office services are also things that just need to happen.
Often the internal IT staff forget that they are providing a service to customers. These customers are internal which in the past have given these IT teams a great monopoly over providing service. That is already starting to change and the IT group that had the monopoly are fighting tooth and nail to keep their services an offering with their group.
One of these key features is performance.
Scalable Development… If You Need Scale Choose Wisely.
I see many different applications at Tier 3 from our customers and how they plan on scaling it in the cloud. This usually becomes a debate about what site is running what application and then another debate about how that site really does not know what they are doing. Here the base examples that I would submit for review…
This really isn’t about what language you think is best overall or how another language sucks. This is really about planning your application and architecture to scale in your environment. The examples above talk about some of the largest social media sites out there that really founded the Web 2.0 era. These companies scale to millions of requests per second and have the growth issues that every company would kill to have. With each of these you can see a common theme that is going on where they first build the application and then scale. I agree with this as a new application you really have no idea what you are going to need until after your first launch.
With any application you should also know what the requirements are for uptime and performance. If you are a web application that is needing to processing millions of transactions you might want to think about the development platform you use as with Twitter they are now moving to a more scalable platform that shows a massive (10x or more) performance improvement just in output with less processor. With Facebook being trapped really is how they look at what their needs are because Facebook is a one in a million tech company who has requirements far above most companies. If you had to scale to the size of these companies would you really be able to do any better? With great success comes great problems…
What You Think You Need vs. What You Really Need
Every business wants to keep costs down and save money, right? Choosing a dynamic environment gives you a way to do just that by ensuring you only buy what you really need…and use.
Most people tell you to only allocate what you need, but of course the theoretical is always easier than the practice. We’re going to help you make sense of this notion, so you can put the theory into practice to cut your costs.
First a little background about where we’ve been before we talk about where we are now.