OpenStack Mitaka Design Summit

OpenStack is more and more the darling of the Enterprise world.  Over the past few years that's changed the development priorities of the community.  With increasing adoption of OpenStack by enterprise customers coupled with the consolidation of OpenStack startups, OpenStack is a changing landscape.

In this free-flowing discussion 3 very experienced stackers will discuss the future of OpenStack and what it means for deployers and users.

• Kenneth Hui - Director of Technical Marketing at Platform9


• Jesse Proudman - CTO at Blue Box, an IBM Company


• Matt Joyce - One of the original DevOps on NASA's Nebula Project

Questions we intend to answer and discuss:

• Is OpenStack still cloud software?


• Has OpenStack shifted its development efforts to support a more monolithic model and away from the horizontally scaled distributed model it was designed to promote?  While there are still large cloud deployments making big waves in the community, increasingly, private cloud adoption at new deployers is targeted at replacing existing VM workloads that have a legacy in the monolithic world of VMWare vSphere.  How does this impact the OpenStack community?


• Is Neutron intended to solve the needs of cloud deployers?  Or is it something else?


• Most hyperscale OpenStack deployers have still avoided the transition to Neutron from nova-network.  nova-network is again seeing development, and there is an admitted conflict of design goals in the two projects that has led to a fracture in how OpenStack is deployed across the community.   The question posed is, does Neutron meet the needs of a traditional elastic cloud, or is it more intended to address the needs of a more monolithic virtualization infrastructure.  What is it’s place in OpenStack deployment?


• Is hosted OpenStack the future of OpenStack?


• OpenStack is still very difficult to deploy, and maintain.  Finding the talent to support an environment has been an uphill struggle for most deployers.  IBM recently made a huge bet on the Blue Box model of hosted OpenStack clouds.  Is OpenStack as a Service the future of OpenStack?  How does the drive to replace costly legacy vSphere infrastructure impact this emerging adoption model? 


• Is the road to Mitaka the road to a collision course with vSphere?


• VMWare is a major contributor to OpenStack.  Nicira who was acquired by VMWare was amongst the earliest and largest contributors to Neutron.  Today VMWare is a member of the foundation board of directors.  And yet, increasingly OpenStack with KVM is finding itself conflicting with VMware vSphere in the market. vSphere is arguably the mainstay product of VMWare’s enterprise offerings.  What does the future hold for OpenStack and vSphere, are these once friendly compliments to each other now beginning to compete for the same market?

One of the biggest barriers  for enterprises interested in deploying OpenStack today is the inability to leverage existing assets - including infrastructure, workloads and their inter-relationships. Committing to an OpenStack deployment typically forces IT to start  from scratch, ignoring any important workloads built up over time. This turns out to either be a non-starter for some organizations, or results in them having to run separate silos of existing, critical workloads, alongside a new OpenStack-based private cloud. However, OpenStack can be taught to learn - and leverage - existing enterprise infrastructure, and incorporate it seamlessly into a live private cloud. This enables users to get up and running with a fully functional private cloud, already plumbed with their existing assets. 

Such learning involves not only an initial pass, but also periodic incremental updates to synchronize the enterprise infrastructure view, with OpenStack’s current state model.

In this talk, we will describe how we, at Platform9, moved our existing dev-test workloads, and infrastructure to an OpenStack-based private cloud, running on vSphere, using a set of such changes for Nova, as well as Glance, which entailed: 

- Enabling Nova compute to discover already existing cloud instances
- Enabling Nova Network  to discover and to integrate existing networks
- Enabling Nova Network to dynamically discover host IP addresses
- Enabling Glance to discover already existing VM images and import them into the Glance repository
- Adding capabilities in Openstack to deal with out of band changes in the cloud environment such as deletion of VMs, network and storage reconfigurations

The benefits that these additions provide to enterprises, in terms of being able to leverage their existing infrastructure within a modern self-service private cloud, are immeasurable. So much so that we made this part of the core feature set of the Platform9 cloud, and believe that it would add great value to the OpenStack project.

Moving Enterprise applications into OpenStack isn’t always easy. Many organizations rely on hundreds and thousands of applications to run their businesses. Migrating those applications one by one can seem like a never-ending journey. Rewriting all of them is not a viable option either. In this session, we will explore a few approaches, from nested-virtualization, containers, and API portability to Orchestration and PaaS, which provide different levels of abstraction, making this transition more seamless. The session will also include real life use cases from large Enterprises (such as TD Bank) and well known Telcos to teach listeners the lessons they learned from their experiences.

PayPal has successfully deployed an OpenStack environment over several availability zones with  300,000+ cores and petabytes of block storage. It is one of the largest OpenStack Cloud hosting ~100% Web, Mid and API workloads for PayPal production and is in operational for 3 years. One of the keys to success has been a tiered application architecture that allowed many front and mid-tier modules to be moved into the OpenStack private cloud, while back-end functions continued to reside on the non-cloud infrastructure. It provided agility and flexibility without compromising on high levels of reliability and availability.

PayPal being one of the early super-users of OpenStack for building Enterprise Grade Cloud, it met mutiple milstones to run its mission crtiical production workloads along with Developer/QA/Stage/Pre-Prod. Recently, PayPal announced that they are running ~100% of production for web, mid and API on OpenStack Cloud. 

Come and join this session for key strategies and guiding princples that PayPal adopted to meet their goal.

Main Topics to be covered:

1. OpenStack Deployment Architecture with Multi-Cells


2. Key Learnings in operating largest AZ with 1000s of hypervisors


3. PayPal PaaS deployment Architecture in OpenStack Cloud


4. Dealing with day-to-day Large Scale issues

As the OpenStack ecosystem experiences consolidation of OpenStack providers, the landscape of tools, platforms, and vendor-provided hardware/software solutions above and below the stack continues to grow. While the variety of OpenStack-compatible technologies means that users and consumers have a tremendous amount of choice, it also presents an ever-expanding set of decisions that must be made by both users and providers of commercial OpenStack Solutions. In this session, panelists will discuss:

• The balance between flexibility/choice and vendor lock-in




• Building loosely coupled/independent services versus fully supported/validated full-stack solutions




• The impact of PaaS, containers, APIs, and application deployment/management methods   




• Barriers to exit and switching costs 




• Emerging technologies and what the community can do to ease adoption and impact for users, operators, and providers 

This is a must-attend session for those building OpenStack clouds, whether you’re building your own or building commercial solutions.

Moderator: Niki Acosta, Cisco Cloud Evangelist. 

Panelists include:

• Shamail Tahir, Cloud Architect, EMC Office of the CTO




• André Bearfield, Senior Director of Product, Blue Box




• Aaron Delp, Technical Solutions Director, SolidFire

Cloud solutions offer vastly improved agility and lower TCO over legacy datacenter solutions. But it can very challenging to move monolithic financial applications from traditional IT infrastructure to cloud-based environments, and to recreate them as distributed, service-oriented, “cloud native” applications with open source tools, new approaches to network communications, high availability, integrity, security, and auditability.


 


ShenZhen Securities Clearing Corporation .Ltd (SSCC) is building an IaaS, PaaS, and SaaS platform for their financial customers. They selected OpenStack as a go-forward IaaS solution, but then faced challenges in building a financial platform based on fully open source software. Mirantis worked with SSCC to fill the gap between OpenStack’s capabilities and feature-set, and their requirements for application management and delivery, and cloud application security.


 


In this session, we’ll share our experience in taking advantage of OpenStack’s flexibility


to design a scalable, reliable financial industry cloud for ShenZhen Securities Clearing Corporation, Ltd. We’ll discuss using OpenStack to provide:


 

• High application availability and reliability in a distributed application architecture with no critical single points of failure





• Robust data integrity and security with new storage architectures and multi-site backup protocols





• New approaches to network architecture and management, access and security, and communications made possible with open SDN

 


Attendees at this session will leave with a much-clearer grasp of financial IT requirements, legacy application debt, and will have in hand a clear, tested pathway to forward migration of critical financial apps onto OpenStack.


 

Ironic is released as OpenStack integrated project from kilo release. Many users, in particular enterprise users, want to use bare metal servers for DB, HPC etc. and so Ironic gets a lot of attention recently. To provide bare metal servers, Ironic needs to manage all the server life cycle. Typical server life cycle is following:
 
 - Register
 - Discovery a node
 - Register a node
 - Introspection a node
 - Ready
 - Deploy
 - Turn on a node
 - Install OS to a node HDD
 - Connect a node to appropriate network
 - Attach volume to a node
 - Boot a node from volume
 - USE
 - Turn on/off a node
 - Access to a node via ssh/console
 - Cleanup
 - Clean up a node HDD
 - Initialize node firmware/BIOS setting
 - Initialize RAID configuration
 - Turn off a node

Althorugh Ironic developers put in great effort on its improvement, there are serveral issues on each stage. For example, there is no network isolation per tenant. That means all Ironic users need to use same flat network. Also, current Ironic supports neithor attaching external storage volume or booting from volume. In enterprise area, users commonly uses external storage to better throughput, latency, lower overhead back up etc. and so this is one of a key feature for them to use Ironic.

To use external storage volume in Ironic, Ironic needs to work with Cinder (and Nova). In this session, we explain ironic current status first and then introduce our effort to realize Ironic and Cinder integration.

OpenStack is getting big in the enterprise, which is traditionally very Microsoft centeric. This session will show you everything you need to know about Windows in OpenStack!

To begin with we will show how to provision Windows images for OpenStack, including Windows Server 2012 R2, Windows 7, 8.1 and the brand new Windows Server 2016 Nano Server for KVM, Hyper-V and ESXi Nova hosts.

Next, we will show how to deploy Windows workloads with Active Directory, SQL Server, SharePoint, Exchange using Heat templates, Juju, Puppet and more.

Last but not least, we'll talk about Active Directory integration in Keystone, Hyper-V deployment and Windows bare metal support in Ironic and MaaS. 

The session will give you a comprehensive view on how well OpenStack and Windows can be integrated, along with a great interoperability story with Linux workloads.

Database-as-a-service (DBaaS), to some, appears to commoditize the knowledge of a longtime stalwart of the corporate IT department, the DBA. Viewed in the broader context of where enterprise IT is headed, DBAs will be the primary beneficiaries of DBaaS services based on Trove: more time spent data modelling and understanding business requirements, less time scripting backups and configuring replication topologies.

This talk will engage the audience to begin thinking about how cloud-enablement and database-as-a-service will alter not only the view of the enterprise DBA but also their value to the organization.

High availability is a very important and frequently discussed topic for clouds at the infrastructure level. There are several concepts to provide a HA-ready OpenStack. And also software defined storage like Ceph is highly available with no single point of failure.

But what about HA if you bring OpenStack and Ceph together? How do they work together and what are the impacts on the availability of your OpenStack cloud infrastructure from the tenant or application point of view?

How does the design of your classic high-available data center, e.g. with two fire compartments, power backup, and redundant power and network lines impact your cluster setup? There are many different scenarios of potential failures. What does this mean regarding building and managing failure zones, especially in case of technologies like Ceph which need to be able to build a quorum to keep up running.

This talk will cover:

• Failure scenarios and their impact on OpenStack and Ceph availability


• Which components of the cloud need a quorum


• How to setup the infrastructure to ensure a quorum


• How the different quorum devices work together and if they guarantee the HA of your cloud


• Pitfalls and solutions

Disaster recovery is an important capability of cloud system. Enterprise pay much attention to DR and ensure their applications are able to survive large scale disasters. Openstack now have volume based replication in Cinder project, it make users could failover and failback their volume by leveraged replication feature in storage backends when disaster happened. But that's not only way to gain DR capability, we would like to share our DR solution and we will introduce how does it work on hypervisor level. We will compare this solution and volume based replication and show the advantages/disadvantages about it. We wish this kind of DR solution will bring one more choice to Enterprise users and their cloud.

There have been lots of discussions in the cloud world about traditional 3-tier application workloads that are highly managed (i.e. Pets) and their modern web-counterpart workloads that are scalable, resilient, and fault tolerant (i.e. Cattle). But how does one migrate business critical applications from a "simple" virtualized world into a hybrid-cloud based on OpenStack?

This talk walks through moving a running web application from one such virtualized 3-tier world into an OpenStack-based cloud world and the sorts of changes that need to be considered for re-architecting the app and re-deploying it into the cloud. The steps are meant to provoke conversations and should not be considered a recipe book.

Hear Andrew Mitry discuss how building out an enterprise wide infrastructure as a service can be challenging. Learn how Comcast navigated challenges such as leadership buy-in, internal “sales”, showback/chargeback, internal consulting, scaling and more.

Michael Bradford discusses what organizational structures worked well for Comcast and how they were able to build an internal vibrant community among their end users.

Chris Mauritz will delineate identified best practices and internal use cases for Comcast’s ‘Elastic Cloud’ as experienced within a rapidly expanding OpenStack environment.

Starting with building a total cost of ownership (TCO) of an OpenStack cloud, we examine the strategic knobs you have available to tune to provide the best solution for your organization. We will introduce the TCO model, as well as using standard financial accounting practices to build a basis for calculating the value your OpenStack cloud provides your organization.

The presentation will provide a basic overview of the accounting principles required, but to get the most out of the model, it helps if you share and talk through with your finance team.

We're receiving a customer's inquiry like this: "Hey, we need to replace our application platform. Can you explain OpenStack? It is good and cheap, isn't it?". Unfortunately, we have seen many people get disappointed after the meeting with this word: "Korejanai! (It's Not This!)". The more people get to know the name of OpenStack, the more disappointments we should see.

It seems that there should be some gap between expectation and reality.

Of course people need to accept the mindset change like "Pet vs. Cattle" discussion for cloud native applications. Not only that, they need to know how to integrate OpenStack into their business strategy.

In this session, we'll present actual "Korejanai" story and discuss how we can avoid disappointment from business strategic perspective.

雲泥の差 (undei no sa) - the Japanese Proverb which literally translated means: "The separation between clouds and mud", implying there is a vast difference between two things. In practice this session is to focus on the difference between "Installing" an OpenStack cloud, from truly "Operating" that cloud...

OpenStack continues to gain momentum and wide spread adoption across organizations of all shapes and sizes. As these groups progress beyond early proof-of-concept evaluations and look to deploy and operate production clouds, they are often faced with the challenges of what comes on day two and beyond (“Now that I have it installed, what does it take to actually operate an OpenStack cloud?”).

In this session we will explore many of the key lessons we have learned that have come from operating OpenStack private clouds of every size and shape over the last few years as a service provider, and share the best practices that we have developed to enable our teams to not just install, but to operate these clouds…

Join key leaders from the Rackspace support and product organization as they share some of the best practices that we have developed in a number of key areas:

• Building Teams - How to think about building and organizing teams, what is the culture and environment needed to help them deliver their best?


• Processes and Enabling Functions - How to instill process and rigidity without impeding your team and your customers?


• The Virtuous Cycle - Building feedback loops and recognizing the different personas you need to serve

Careless capacity management in the cloud can get you into trouble because storage can grow almost invisibly over time. If you wait until the cloud is almost at capacity, two things can happen: 1) hardware lead times can cause you to hit capacity limits before the new hardware arrives, and 2) a sudden spike in instance usage can cause you to hit capacity before you had originally planned. (This can be compounded by #1 if you're not careful.)

After gathering a lot of data from multiple regions of a very large cloud over the course of a year, I was able to see growth patterns over time. These patterns enabled me to determine upper limit percentages (utilization) from which to trigger the hardware ordering process. Couple this with a solid understanding of the lead times from your hardware vendor, and you should be able to keep the cloud from hitting maximum capacity before new hardware is racked, stacked, and assimilated. Working with standard hardware configurations also makes this process faster and easier. You must also keep in mind what “size” of hardware to buy so as to scale out rapidly without causing problems due to a single hardware node failure.

During this session, I’ll discuss:

1. Best practices to chose a standard hardware configuration that is rapidly scalable and will not cause severe ‘boot storm’ issues if a failure happens


2. How to plan for initial server counts for a new cloud or region and set apredictable growth trend for usage in that cloud


3. Recognizing when to trigger the hardware procurement process so that it aligns with projected growth and known vendor lead times

After attending this session you’ll be able to employ capacity management best practices to ensure maximum service uptimes, minimum service disruptions, and ease the transition of capacity expansion.