Snip/Shot by Toddy Mladenov

Open Source in the Cloud - How Much Should You Care?

Tweet

In his opening keynote for Red Hat Summit, Jim Whitehurst, the CEO of Red Hat asked the audience: "Name an innovation that isn't happening in Open Source - other than Azure!" I can certainly add iPhone and AWS to the mix but let me stick to the cloud topic with the following question: "How much Open Source matters in the cloud?"

 

Let's first elaborate on a two misconceptions about Open Source.

 

Open Source is Free

Not really! In the cloud doesn't matter whether you are running on an Open Source platform or not - it is NOT free because you pay for the service. And for long Open Source project have been funded through the services premiums that you pay. I would argue that Open Source vendors have mastered the way they can take profit from Open Source services and are far ahead than the proprietary vendors. The whole catch here is that you pay nothing for the software and incur no capital expenditures (CapEx) but you pay for the services (i.e. Operational Expenditures or OpEx) - remember, this is also the cloud model. Bottom line is that you may be better off with a propriatery vendor than an open source one, because the latter needs to yet master that business model.

 

Open Source Means No-Lock-In

Not sure about that too! Do you remember J2EE? It wasn't long time ago when Sun created the specification and said that there will be portability between vendors. Those of you who have tried to migrate J2EE application from JBoss to Weblogic to WebSphere will agree that the migration costs weren't negligible. It is the same with Open Source clouds - doesn't matter that HP and RackSpace both use the Open Source OpenStack - you still need to plan your migration costs.

 

I am far from saying that Open Source is not important. Quite opposite - I am big Open Source fan and the biggest example I can give is… well, Azure. They also understand that the source is not important anymore hence they open-sourced their SDKs (and continue to add more). It is time to forget those technology wars and really start thinking about the goals we have and the experience we provide for our customers. When you choose your cloud providers you should not ask the question: "Are they Open Source or proprietary?" Better questions to ask are:

• Does the vendor provide functionality that will save me money?
• Can they support my business for the next 5 or 10 years?
• Do they provide the services and support that I need?
• Are they agile enough to add the features that I need?
• Do they have the feedback channel to the core development team that I can use to submit requests?
• Do they have the vision to predict the future in the cloud?

All those are much more important questions for your technology strategy and your business than whether their cloud is Open Source or not.

10 Dos and Don'ts for Running Proof-of-Concept Projects in the Cloud

Tweet

With cloud computing increasing its popularity, more and more enterprise IT and development teams are looking to run proof-of-concept projects. Very often though such projects do not deliver results as expected and project managers come back to the leadership teams with either: "We are not ready for the cloud!" or "It will be too expensive to move our applications to the cloud!" However the problem doesn't necessary lie in the cloud or the application portfolio. Most of the times it is in the way the project is scoped and managed. 

 

Here are few DOs and DON'Ts for managing proof-of-concept projects in the cloud.

 

DOs

• Make a decision what type of cloud options you will evaluate - from a service model point of view and from deployment point of view. If you are going to evaluate private PaaS options try to compare those only to private PaaS providers. Using the well known cliche compare only apples to apples.
• Clearly define the terminology for the whole project team. For example something that one company calls PaaS may be considered IaaS or just a stack automation by another vendor. You need to have your own definition of PaaS, IaaS, stack automation tools and any other terminology that you will use.
• Choose only vendors that fit your definition. After you clearly define and socialize what you will be evaluating you need to choose vendors that offer solutions that fit you your definition. 
• Select application that will be easily migrated to the cloud. Quite often teams select their most complex application but the problem with this is that such applications are very often implemented with legacy technologies and most of the time gets spend on re-architecting the application instead learning what the cloud has to offer.
• Set clear goals and timeframe for the PoC. You need to be clear what problems you want the cloud to solve for you. Whether it is agility and time-to-market, or efficiency and ease of infrastructure management you need to get the whole project team to agree upon. Next, make sure the project is time-boxed and properly managed to come up with meaningful results.

 

DON'Ts

• Don not rule out particular technology because you are not familiar with it or it is too new. One of the goals of the PoC should be to become familiar with the technology. In addition new technology may solve more problems for you than you have initially anticipated.
• Do not select too many vendors. Choose only the best 2 or 3 vendors in the category you want to evaluate else you may fall into analysis-paralysis and not be able to choose among the variety of options you have. In addition the PoC will run longer the more vendors you have.
• Do not migrate multiple applications as part of the PoC. Migrating one application should be enough for you to learn what the effort is and become familiar with the technology or the vendor. Migrating more than one application is investment that you may not stick with after the PoC.
• Do not extend the length of the PoC. Even if you think that you will be able to migrate your complex application to the cloud if you extend the PoC with another month it is better to cut the scope instead. The reasons are that 1. you have already learned that you will need more time to migrate your applications to the cloud and 2. extending the PoC postpones the decision and moves you further away from the ultimate goal to get everybody on-board.
• Last but not least do not make decision that is heavily tailored to the needs of one team. If the PoC is a cross-team effort (IT, DEV, Business) then all three teams should have equal saying on the technology. If one of the teams targets additional goals they can evaluate technology that easily integrates with the chosen one and offers complementary benefits.

 

Making a technology decision has always been tough choice hence having a structured approach to the problem can help you make the decisions faster and last longer.

Multi-Tenancy Options in Cloud Environments

Tweet

One of the biggest benefits the cloud offers is the ability to colocate customers and applications on the same hardware in order to improve the efficiency through resource utilization. This type of colocation is referred as multi-tenancy however the term becomes overloaded and it is crucial to understand the different types of multi-tenancy out there. This is especially important when you are building your private cloud because your goals may differ from those of the public cloud providers who try to satisfy the requirements of a much broader audience.

 

Now, let's look at the different options that are available.

Multi-Tenancy at Infrastructure Level

One of the most common approaches of multi-tenancy is the one implemented at the infrastructure level. This is the widely popular IaaS (Infrastructure-as-a-Service) approach, where you can host multiple customers and/or applications on the same hardware by using separate virtual machine for each. The benefits of this approach are:

• Maturity - virtualization has been used for a while already and the technology and the tooling available is pretty advanced
• Easy to implement - there are many out of the box products available on the market that can get you up and running pretty fast
• Legacy app support - you will be able to run legacy apps that are not cloud-enabled with little migration effort

However there are quite some disadvantages of this approach that you need to take into account:

• Decreased infrastructure efficiency - in order to run multiple VMs on the hardware you need to 1. use a hypervisor to run those and 2. install separate kernel on the guest VM; both of those use part of the resources on the machine for their own needs leaving less for your application
• Increased license costs - the hypervisor and the guest operating systems may require additional licenses, which increases your capital expenditures
• Higher maintenance costs - with the sprawl of VMs that you have you will need more time to update, patch and troubleshoot your environment
• Developer unfriendly - although it solves the machine provisioning problem it may not solve the application deployment and maintenance problems and it will continue to impact your time-to-market. One note here is that there are quite a few tools available on the market that you can use for application provisioning automation however their integration with the underlying VM management software is still not mature enough

Multi-Tenancy at OS Level 

The next option you can choose from is to use application containers for multi-tenancy. This is more advanced approach where you use containers that run on the same operating system and ensure access only to resources allowed for the application. There are several benefits to this approach compared to the IaaS one:

• Higher density - because you don't need to run a hypervisor and separate kernels for your application you can deploy more useful workloads on the machine compared to the IaaS approach; the overhead for running the container is much smaller
• Lower licensing and maintenance costs - there isn't anymore the need to pay for hypervisor and guest OS licenses; the license cost for the container management software is comparable to the license cost for IaaS management software that does not include hypervisor and guest OS licenses
• Developer friendly - because the containers are specialized pieces of software that target specific types of applications they already come with a complete application stack (like J2EE, IIS/.NET etc.) and application deployment support
• Application Standardization - because the platform itself takes care of the application stack build-up you can achieve high level of standardization between applications; in addition the platform may offer standard services that can be used by each application

Some of the disadvantages of the containers approach are:

• Limited legacy app support - containers are well-suited for deployment of applications that are developed with service-oriented approach in mind (SOA); legacy applications that assume certain machine or OS dependencies may require significant efforts to migrate
• Maturity - the containers approach is new compared to the virtualization one however it is picking up speed fast and you can expect to see more in the coming months and years; the tools support and the integration with the underlying infrastructure can also be limited

Multi-Tenancy at Application Level

Last but not least is the approach where you implement multi-tenancy in the application itself. Although this is the approach where you will achieve the highest density of your infrastructure there are certain disadvantages:

• Very costly - in addition to the actual functionality of the application it needs to also be instrumented for resource management, which can become a significant work item
• No standardization - each multi-tenant application ends up implemented differently because there are no standard infrastructure services that can be used
• High maintenance costs - because each application has a different approach to implement the resource management the maintenance costs grow with each new application

Having good understanding of the multi-tenancy options is crucial when you make a decision for your private implementation. Weighting out the options and getting feedback from various stakeholders in your enterprise - developers, operations, business - will help you make the best choice for your cloud strategy.