May 4, 2012 0

Five Reasons PaaS will Rock the Enterprise

By in Cloud, DevOps / NoOps, Enterprise, IT, Thoughts

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 HerokuEngine YardMicrosoft 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.

What is this PaaS thing?

Platform as a service (PaaS) is a category of cloud computing services that provide a computing platform and a solution stack as a service. In the classic layered model of cloud computing,[1] the PaaS layer lies between the SaaS and the IaaS layers.”

[Wikipedia: http://en.wikipedia.org/wiki/Platform_as_a_service ]

Platform-as-a-Service is a framework for running applications and consuming services that handles many standard IT operational functions such as deploying, optimizing, and allocating resources, scaling/load balancing, health monitoring, and service discovery – all without manual operational intervention. In essence, it gives control to the business, product, and development teams to perform their job without requiring IT to be involved and causing a bottleneck.

PaaS is still in its early stages, but it is growing into a standard faster than even virtualization. Teams starting new projects are already considering using it or have enabled it in their dev/test environments.

For more information about PaaS check out Removing the Operating System Barrier with Platform as a Service (PaaS) – a guest post from Adron Hall.

1. Services, Deployments, Scaling, and Monitoring

IT organizations are constantly struggling with building and maintaing a standardized way to enable services for their customers, allow seem less deployment and integration with existing systems, scale to meet the demands of the business, and give all of these things with monitoring and a good service level. This is very hard to do  – not because there wasn’t a true effort to have and enforce the standard — but because the platform itself didn’t create and dictate the standard

With PaaS services are defined in the system automatically for consumption enabling standards by default without any manual configuration or validation.

When your team deploys to a Platform as a Service, the system is built to deploy the application for you across all instances and services–relieving the operations team from the task of manually doing a deployment.

. This also enables continuous integration to start happening where deployments can be more regular. Scaling of instances are easier via standardization as you can now easily scale up and down the amount of instances needed which the platform will handle the process of adding and removing instances for you. With health monitoring when an instance fails the platform will work to heal itself by moving that instance out of rotation and spinning up another one to replace it.

2. Staffing and Teams

Even with the downshift of the economy, tech jobs are in demand.  Many companies struggle to find and hire developers.

We can all agree that there are insufficient numbers of engineers graduating from college to meet demand.

. What we don’t agree on is how business will be able to bring on engineering/development talent without struggling.

With a multi-runtime platform as a service offering inside the company – one that can support multiple development languages on the same platform — hiring is much different.

. Now don’t start an engineering job description off with a list of supported languages, instead list all of the languages supported by your PaaS and then just focus on hiring a rock star who can add real value. PaaS  opens the market, enabling you to go from a one or two language shop to a 5+ language shop. Teams can now choose the language they prefer – or the one that is ideal for a projects –  and hire from there. For example, you could have two java teams, one .NET team, and three python teams. PaaS gives you so much hiring flexibility and thought leadership that you can enable a developer to branch out and try other things.

3. Adopting Technology is Easier

IT organizations are becoming more critical to business competitiveness and agility everyday. To enable this agility that the business needs from IT new services and IT based projects have continued to grow while staff has not grown to meet that demand. With all of these new services and projects the technical debt of maintaining these solutions grow exponentially making adopting these new services and projects harder.

By enabling a PaaS into the organization the transfer of application ownership can be maintained by the development team and business application owners with a supportive role from the IT operations team as the standardization is built into the system itself instead of maintained by manual IT process.

With built in service discovery and modular based architecture for services in PaaS the IT organization has a pattern and best practice for bringing on new services and features that are easily enabled for the organization. Already platforms such Cloud Foundry support over 7 runtime languages, multiple databases, and messaging systems.

4. Enabling Standardized Consumption of Services

Today enabling/provisioning IT resources is typically very difficult to achieve.

. IT organizations have to keep pace with constant technology changes and all the effort in bringing new technologies into the fold to be supported. This often creates multiple “one-off” offerings that are more difficult to support across the organization.

With PaaS, discovery of services are built directly into the platform for easy integration and discovery . Developers, application owners, and operations can easily manage and architect their application with standardized scaling, monitoring with best practices built directly into the service. With the built in flexibility and standardization of PaaS the operation team can now focus on the platform itself and not creating multiple “one-off” scenarios.

5. IT at the Speed of Business

Within most companies there is the “IT Department” (yes, I am over generalizing). Business teams often consider this department stagnant and a major cost center for operating tasks. Strict policies, limited flexibility, project delays, not using the latest and greatest software, slow development are common complaints causing business users to work very hard to avoid IT.  The IT organization is simply not able to move at the “speed of business” because they are working to maintain legacy while also offer value to the business.

By moving to PaaS not only are you enabling the rebirth of what IT is to your business, but you are also creating the agility needed for the business to thrive. Standard processes built into the core of your environment that enable delivery of applications with the scalability for the demands of the enterprise will streamline your development and delivery to your users. Being able to use the platform to recruit from the broadest possible pool for the best talent available without restriction is key.

March 20, 2012 0

Hybrid Cloud 101: What you should know

By in Cloud, Enterprise, Software

A BrightTALK Channel

Tags:

February 8, 2012 1

Four Golden Rules of High Availability

By in Cloud, High Availability, IT, Scaling

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…

Baseline Setting

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).

Here are the standard percentages, amount of service disruption, and some context on each one:

Availability % Downtime per year Downtime per month* Downtime per week
90% (“one nine”) 36.5 days 72 hours 16.8 hours
95% 18.25 days 36 hours 8.4 hours
97% 10.96 days 21.6 hours 5.04 hours
98% 7.30 days 14.4 hours 3.36 hours
99% (“two nines”) 3.65 days 7.20 hours 1.68 hours
99.5% 1.83 days 3.60 hours 50.4 minutes
99.8% 17.52 hours 86.23 minutes 20.16 minutes
99.9% (“three nines”) 8.76 hours 43.2 minutes 10.1 minutes
99.95% 4.38 hours 21.56 minutes 5.04 minutes
99.99% (“four nines”) 52.56 minutes 4.32 minutes 1.01 minutes
99.999% (“five nines”) 5.26 minutes 25.9 seconds 6.05 seconds
99.9999% (“six nines”) 31.5 seconds 2.59 seconds 0.605 seconds

[calculation required] * For monthly calculations, a 30-day month is used

Chart Provided By: Wikipedia: High Availability

Now that you have a baseline, let’s talk about…

The Golden Rules

  1. No Single Point of failure: This is the most common starting point when building a high availability system, but in truth it is very hard to do. Most complex systems need to be able to write back transactional data to a centralized database layer. Even with clustering there are parts that don’t handle partial failure well. A better architecture for high availability is for easy fail over to alternative backup services with the ability to bring it back online and sync data. The application layer needs to be more aware of failure and work to heal itself. Remember, with datacenter facilities there is no such thing as 100% uptime, no matter how good their N+1 configuration. Eventually at some point they willmiss a beat. In the end, leveraging the flexibility and cost structure of the cloud is a better solution than building your own two facilities.
  2. Self-healing is Required: When it comes to the application layer, self-healing is one of the hardest thing to do. There are so many possibilities.  From my experience half of the things you thought would have issues — and spent a lot of time architecting for — just never happen. While it is always good to add some of the architecture around the standard items such as service and datalayer fail over, in the end as the system/application is rolling out you will start to see what components have the greatest possibility of failure.
  3. It will go down so plan on it: No matter how good your team is or how amazing the architecture is, or even if you are “cloud powered,” your application will have disruption in service. When that happens (and it will) what is most important is how fast it can recover.  By developing good monitoring tools and ways to quickly diagnose the issues, recovery will be much faster.
  4. It is going to cost more: Many times you will hear from the business that their application should “never go down!” The discussion instead should be what downtime is acceptable for the business.  Find out what is that number really is and move towards it. If you do not have the honest discussion with the owner of business owner of the system/application, then you should never build it!

Is cloud changing this?

You have probably heard that just by moving to the cloud your applications will never go down. That is what happens when marketing gets involved and starts to sell false hope. The real truth is that cloud providers are on the forefront of giving better high availability than you could achieve yourself. Where they can — and where it is cost effective — these providers are building high availability into theirsystems. They offer an SLA (Service Level Agreement) with ramifications (usually financial) if there is service disruption.  These SLAs incentive them to build in as much high availability as they can and to quickly respond to any service disruptions. That level of SLA is very hard to achieve and carry out inside a larger enterprise IT shop, and almost impossible for a mid-size business to do themselves.

But.. but… Netflix did it on a provider that doesn’t have a great SLA!

Yes and when you are the size of Netflix with hundreds of engineers working on your service offering, then you can do the same. If the provider does not have a good SLA then you need to walk in with eyes wide open to the reality that the availability will be handled only by your application.  In most cases this will be more costly than picking a good provider. Why?  Developers are expensive.  On the other hand, working with a cloud provider that delivers a strong SLA and high availability in the underpinning infrastructure should reduce the overall cost dramatically over doing it all at the application layer.

What is very unique about the cloud today is for the first time there are providers focusing only on making your application work better and providing instant access to resources.  All of this flexibility and all of these best practices delivered as a service offering. Cloud is enabling the business to easily architect for high availability. Cloud providers can provide multiple data center locations to deploy your application across multiple regions which is WAY cheaper than building two of your own data centers forhigh availability. They are also moving more difficult items “as a service” for built in high availability — such as database as a service where it will setup replication and fail over for you.

The next big thing to watch with cloud providers is “platform as a service” or PaaS. This technology can instantly deploy your application across multiple datacenters with a few clicks of the mouse.  PaaS is in its young adult stages but is gaining rapid adoption. These innovations are the key reason you should use the cloud as they are focusing on making HA easy inherently while you focus on your application/business.

In Short…

  • Will the cloud have outages? Yes
  • Will the cloud have less downtime? For the most part, Yes.
  • Is Cloud going to be cheaper than doing it internally? Yes.
  • Should I use the cloud for my application? Unless there is a compliance reason, Yes.
  • Will the cloud be more innovative at enabling and automating the infrastructure layer for my application? Loaded question, but I have to say Yes as that is what cloud providers focus on.

Conclusion

Let’s be honest:  The biggest problem with high availability is setting the right expectations with the business/consumer and being transparent on the reality of what they should expect. Today many people consuming these systems/services are told that “no matter what the cloud makes so your applicationNEVER goes down.”  Not true. While it does help a lot, you can achieve better availability with the right SLA and application, cloud marketing has failed by setting false expectations.

The cloud is getting better every day and is focused on providing a better environment with high availability, but… things will go down. By remaining transparent on your goals of availability and following the golden rules with the cloud and your application, high availability is not only achievable and cost effective, but also easier to achieve than ever.

November 21, 2011 0

Why operations will be transitioning to managing clouds and not applications…

By in Cloud, DevOps / NoOps, IT

http://cloudpundit.com/2011/11/21/why-developers-make-superior-operators/

Another good article on the current and changing dynamics of operations and developers. With platforms becoming easy to manage the application layer through automation the developer and business will be able to operate more applications with less reliance on an operations team.

This is a growing trend that is not going to stop anytime soon and I see that the operations teams will be working towards managing these clouds as a service for the business units and application developers. In the end less time will be focused in operations at the application layer and more around resource management.

November 11, 2011 0

Why IT is not the face of business buyers

By in IT

Great post by Lydia Leong about this topic.

http://cloudpundit.com/2011/11/10/in-cloud-iaas-developers-are-face-of-business-buyers/

There is a changing trend that has been going on for decades now and is about to hit a major tipping point where IT organizations will be greatly affected. This change is that computers now are not only critical to business but also give the competitive advantage and the business knows this . When this happens, the IT organization will be replaced if they fight moving to a more “Agile Infrastructure,” where the IT organization is offering a platform to their customers, “the business.”

This is also a huge enabler:   the IT organization has a chance to really shine as it becomes more like the development team than a “cost center. ”   IT becomes a strategic partner to business by providing a robust internal platform and also moving up the application stack, focusing on business needs such as implementing messaging and collaboration or other new trends that give the business a competitive edge.

November 7, 2011 0

Is Judgement the number one trait for a developer?

By in Development

Great blog post from Tammer Saleh on the number one trait for a developer: http://www.engineyard.com/blog/2011/the-number-one-trait-of-a-great-developer/

The only thing I would wonder about here is that the definition of a rock star is usually their experience + their ability. Without judgement I doubt you would have a rock star as experience comes from having good judgement and making the right decision. Ability uses judgment to figure out really what should be learned and focused on.

Here are some of the traits that I always look for in a developer to define them as a rock star:

  •  Experience
  • Leadership
  • Problem Solving
  • Team focused
  • Hard worker
  • Passionate

Just a short list that I see as a developer can be a really good coder but in the end to become a rock star it is the list above that makes it happen.


 

November 6, 2011 0

Should you use MongoDB?

By in Cloud, Database, DevOps / NoOps

With all the craze going on with NoSQL and new databases people should really evaluate what you need. This article is a great evaluation of their experience with MongoDB:

http://pastebin.com/raw.php?i=FD3xe6Jt

Here is another response to MongoDB also that should be looked at:

http://blog.schmichael.com/2011/11/05/failing-with-mongodb/

November 3, 2011 0

Wow. AOL has 3.5 Million dialup subscribers still?

By in Uncategorized

http://www.businessinsider.com/35-million-people-still-subscribe-to-aols-dialup-service-2011-11

Does this show how bad our infrastructure is in the US? Where is all that promised broadband?

October 7, 2011 0

Old school customer support is out! 3 ways to increase your customer support experience.

By in Cloud, DevOps / NoOps, IT

There is a major change happening with customer support and many companies really haven’t got it yet. Customer support is now about the reaching the customer in their support channels and less about the customer reaching you.

A great blog post from Sandy Walsh talks about how old school support really just doesn’t work and the main goal for the old support system is to not have anybody contact them. Customers are expecting more and here are some simple ideas to increase your customer experience and reach:

Offer online chat capabilities right on your web site with REAL your elite customer service people that will make the experience magical.  

Many times I hear about companies that are offering online chat for support and after using it people realize the person they are chatting with are either outsourced or beginners. That is the WORST thing you can do as many of the customers that will want support online are the power users and could be the most vocal. Instead of placing level 1 on chat think about placing your companies elite. This will give a great customer experience and also enable your elite team to multi-task by helping many customers.

Monitor Twitter, Facebook, and other social places that your customers are on. Then Respond!

This seems like a simple task but really it takes a lot of time to figure out the keywords and tune it to be able to respond with good answers to your customers. Many new support systems are adding Twitter support which is key as it helps maintain things such as ticket tracking. Other items is to work very closely with the marketing, and sales team on their twitter feeds to be able to notify customers or respond on any issue.

Notify customers of issues via Email, SMS, Twitter, and Facebook, and even voice so that you are now reaching out to where they are.

Find out how your customers like to be notified of issues and then enable that in your system. The main goal here is to make sure your customer knows what is going on and can also give a good response. You think that I am crazy for even suggesting to do SMS and Voice communications but there are companies now that will enable this such as Twilio which via an API you can do voice calls and also SMS.

Finally, Be transparent with your customers and they will respond.

October 4, 2011 0

Why proprietary software is mathematically more evil than open source

By in Open Source, Software

http://blog.gardeviance.org/2011/10/why-proprietary-software-is.html

Love this blog post by Simon Wardley. J

One thing that I often think about is Software as a Service companies as they look more and more to me as proprietary software using open source as they don’t have to give away their code and it seems that the community that frowns on anything proprietary loves them.