[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: The business case for OpenShift

A few comments about some future direction of OpenShift, and how it might affect the business cases you mention.  I'm speaking less specifically about OpenShift Online than about OpenShift as a project below.

On Jan 2, 2015, at 2:16 AM, Andrew Galdes <andrew galdes agix com au> wrote:

Hello all,

I don't want to come across as pessimistic but rather optimistic to see the light. 

We love the OpenShift technology and we're investing plenty into education for staff and we provide limited (and slowly growing) OpenShift services to our clients. However, we're having a hard time identifying the business case from the clients point of view to adopt the technology as a solution. We conclude that, like all technology, its focus is just that and we should use the right tool for the job and OpenShift won't always be that tool. 

Our web-dev clients we can see benefit from it. It's a saviour for them. However:
  • Businesses with simple 'brocher' or 'business card' type websites have no need for it. 
  • Businesses with retail sites need large databases, opt for iaas for high-tuned and customised environments and need fully customisable environments.
  • Businesses with application websites have their own special infrastructure needs and inter-system communications and often like it onsite. Also the possibility of large DBs.
In this specific case, our general story is that is why OpenShift is an open source project with an enterprise support focused story - to allow these users to deploy their own OpenShift.  But even those organizations can find benefits in having aspects of their web dev and development flows running on the Online version.  For greenfield apps, this is always a much easier story, but there are many existing apps with components that are suitable to the OpenShift model as it exists today.  This "hybrid" model we expect to grow as organizations become less attached to physical infrastructure (internal or external) and focus on application definition and composability.
  • Start-ups with apps in the making are worried that the DB growth issues may well become an issue sooner rather than later. 
So other than OpenShift being a cool technology servicing web developers, who else can benefit?

Databases definitely are a linchpin of many "growth scenarios" where someone is transitioning from idea to production and then growing past that.  Our goal has always been to provide a reasonable foundation for that flow (starting with simple, push button db deployments) but as you note in some cases the need to tune and manage that DB works at odds with the current OpenShift story.  Today, that story might be DBs managed externally (by an in house team or an IaaS service), but a degree of planning is involved in how you transition across those scale boundaries.  Going forward, I see two improvements to that story:

- newer databases (nosql and sql alike) are increasingly self tuning and have lower operational overhead to scale, which reduces the cost to prepackage and deploy them on top of infrastructure (as VMs, or as OpenShift cartridges) in a scalable way

- that OpenShift is moving towards making database like components easier to deploy and manage themselves by leveraging paas and IaaS ideas (offering finer grained controls on those components).  A large part of the OpenShift 3 architecture is around the idea of finding a lower level of common building block for all networked software, not just web dev style solutions.  E.g. Several blog posts recently about large companies using massive Cassandra clusters inside Docker containers in production - that story would directly carry over to OpenShift in our next gen architecture, so a blurring of the lines between web dev and other types of networked apps.

So over the longer term I see a future where there is increasing ability to deploy databases as needed and scale them on OpenShift, with deeper visibility into the underlying tuning to make vertical scale databases work efficiently, while being able to centralize operational and monitoring workflows across many different types of components.

A little maths shows the costs with Origin on EC2s pushing the acceptable cost barrier:

An EC2 of m3.2xlarge costs $564 per month and has 30GB RAM supporting 60 small gears. That's $9.50 per gear per month. Based on per hour costs and in AU$. The server would need to be running at 100% customer utilisation (not resources utilisation). The PaaS supplier would need to add their margin pushing the prices above the current options. There are always exceptions and the reserved prices are considerably lower. 

I fully understand that any business could host their website and/or web application on OpenShift which is great but as it stands, their sites are working fine and the recourses to provide OpenShift instance is larger.

Happy new year. 

-Andrew Galdes
Managing Director


AGIX Linux

Ph: 08 7324 4429
Mb: 0422 927 598

Find us: Website | LinkedIn | Blog | YouTubeGoogle+

Platform Architects for High Demand Web Applications.
users mailing list
users lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]