 Well, good morning This is an amazing conference I'm absolutely astounded at the amount of information we've seen so far in this show everything From Juno to juju and all the rest of the alphabet letters as well The vendor exhibits the information that we are gathering as consumers or as developers on this product It's just absolutely amazing. In fact, it is so good. I want to leave And you see Cloud is not just a new buzzword open stack is not just the new cloud OS But it's opening up a whole new cloud paradigm for each and every one of us That's attracting thousands of users thousands of developers analysts and everybody from Enterprises through to startups is trying to figure out How do I harness the power of this cloud and so why do I want to leave? Because I believe that the only way we can truly leverage what open stacks brings to the table is To move our application portfolios to cloud To open stack and that's why we've got work to do Especially over the last five years. I have worked with many different teams software development teams operations teams business marketing sales teams and I've seen a common pattern that's emerged across those interactions And it's about that pattern that I'm going to speak in this session today And so I want to say the stage here in the beginning This is not a session full of thousands of details But it's a session about providing your framework a taxonomy if you want to call that That as you move through the same process in your world you can collect information and the idea is is that you start with an existing portfolio and When you are done you're starting you will end up with a cloud optimized portfolio Let's look at the business reality Not all applications are born multi-tenant agile Delivered in one-week sprints through test-driven software development through CI CD and pair programmers On an elastic multi-tenant cloud, right? Unfortunately, I think it was nice to think that is the way everything starts, but the reality is quite the opposite The reality is as much of our portfolio Our collective enterprise portfolio is still Waterfall it is still thick clients and it's old code and so cloud always and opens that comes up And it says what do I do now on the other end if we look at our resources? Our resources is good at 12 months print, right? They are so deeply embedded in their code They have hundreds of years of collective knowledge and they use IP to protect job security or hesitant in taking risks and They don't want to change the status quo, but Our customers and our CEO is asking us What are we doing about this cloud? How are we going to use it for our organization? The wheel has turned and there is no going back So as we go into the cloud model knowing the business reality I've had many conversations early along in the in the cloud path That says well, you should just go agile, right? And then I had a couple of frowns stairs there at me and says no no we don't do agile We do waterfall, but I've heard all of these good things about cloud and so easy to spin up VMs And I can destroy it and I don't have the restrictions of what I face today But I can't just go cloud agile and so in those interrogations We've realized that there should be a first step and that's step. We started pulling cloud friendly Contrasting to an on-premise product or a legacy product this first band in the model is about cloud friendliness It's not specifically where you're gonna make money if you're a vendor It's not specifically where you will have ecstatic enterprise users, but it's an entrance point into the cloud From cloud friendly you move into a cloud ready And on cloud readiness as you're starting to harness more of the power of cloud and From cloud ready. We eventually end up with a cloud optimized model Quite interesting as well is that as I had those discussions with various teams those teams seems to fit into three general groups And so the first group is the business domain And we'll deep diver into who those people are but it's typically the product marketers The relationships managers in the enterprise Those guys that's pitching cloud, but they don't have a cloud portfolio in front of them yet It is our general counter council. It's the lawyers that's got to set up the contract It's the service management teams that's got to set up an SLA with the consumer of this cloud product They don't know specifically how to write code or how to operate it But they often take the tip of the spear for us. And so this domain of people came out in the model The second domain I think is the one that most of us is quite familiar with is our software development teams And so keep in mind from a legacy perspective We've got waterfall moving and many enterprises to agile in many I've seen different teams one team takes waterfall products while another team comes up along their side and start building agile and see see both But quite often it's with an intention to move into a modern agile world And so the software development is what I call the technology domain and then lastly We're looking at the operating model model or the operating domain and there's two specific groups that I Classified inside of this domain. One is the operations team and we'll talk in this session about operations moving to Hosted operations moving to DevOps and the second one is our security teams Very important to understand that once we move into the cloud paradigm that security eventually is not in after thought As quickly as possible it becomes part of the development cycle so Going through many different products and I'll give some product examples without naming the guilty parties as we go through this process An engagement typically for me would start with an architectural review and I would like to love love to look at the software and how's the software constructed Where does the software come from from a technology perspective? So I would look at an architecture review and I would ask the developer or the operator or the person that knows most about this product So he's described your product to me in three tiers. What is the front end component? What is located on the desktop? What is the web? Is there a web interface? I would kind of from there look into the middle tier components. This what is the application? Integration look like do you use queuing or not? Do you have proprietary protocols? Well, it can it function across a multi-tier Network and then I look at the data model. How do you store content very seldom? Do I find them on a lithic system that is multi-tenant by design again? That's our in-state and so with that as information a basic understanding of the application I would go sit down with the sales guy and so one of the first things I've realized is that Companies or internal providers often start selling cloud Before they've got a licensed contract And I can't tell you the number of times that I've sit in front of a client Deep into the sales cycle When they look at the contract that's placed in front of them and they say Skulk You have told me that you are providing me a full cloud system Equivalent to everybody else in the world, but when I look at your contract It's talking about licensed software and that's from a non-technologist So you should take your old license contract You should take your old service agreements inside of the enterprise and you should start introducing cloud terminology Inside of it for instance, you cannot commit to staying in one data center On premise did not have that concept you sell the software or it delivered the service and that consumer again within the Enterprise or from a vendor perspective outside They had full control about where it's going to be installed But in a cloud contract you cannot limit yourself to that so you should start introducing terminology That says I as a service provider again inside or outside has the ability Legally to move your data wherever it is and now you could become very specific You could say is well, I will involve my customer from a change control process I will guarantee that it will be within country borders So you could become very specific there, but you take one customer you start with your existing contract and you start changing that language You should have a basic SLA many people come to me and says as well We want to go cloud and I would love to have ninety nine point nine nine nine percent availability and I said welcome back once you've Got a different perspective Because in an on-premise environment there is often expectation that the system will never go down The reality is far from that if we look at systems across the Enterprise Often inside of our network. We've got much lower availability, but the reality is we don't measure that So as a cloud provider as a company using cloud Operating systems you should set a target of ninety nine point five percent and with that ninety nine point five percent In your contracts, they will be certain penalties License software does not have those penalties So you should start thinking now is how do I commit to that SLA and then also afterwards? How do I measure it because from time to time they will be a penalty that will be leveraged against the provider There should be a basic services agreement On-premise software again or inside of the network Software it's got a different style of Services we go through more of a lifecycle of developing software and supporting it as a cloud provider So look at your services contracts and in specific in those services contract You need to touch on the roles and responsibilities What is your responsibility to the provide as the provider and what is the responsibility of the consumer at the end of the Day a cloud system will only be Successful if you retain your customers too many of our enterprise customers Bypass IT because not only are they frustrated But they are competing against an industry who makes its money in retaining customers So don't just think software but start thinking about a service model with a focus of retaining your customers right as we move from The the the business domain into the technology domain in this cloud friendly band We quite quite often find fat Clients so a fat line is to find a software running on a desktop Connecting to some kind of a desk a back-end to very common characteristics immediately comes out number one That fat client has got unlimited bandwidth. There's no concept of internet Number two Quite often you will find that the fat line and Downloads huge amounts of information proprietary content PII information to the desktop and Run some SQL statements on the desktop and then sends it back all without it being encrypted So those are the two common things that you've got to look at now Unfortunately, these fat lines has been developed over the last 25 years or five or ten you take your pick And so it's not easy to take that flat client and build it over into a thin web client But in today's world of business intelligence as you can sit down and you can say is what is the most common? characteristics that hits 80% of my user base that I need to build into a web client and So that will cover maybe 80% of your users But you retain the fat lined in some way or shape maybe through a VPN connection to the service provider For the power user or for the administrative user and so your development team start now thinking in web interfaces and API's Where previously they only had a fat line available? Again quite common to see a monolithic application when you speak to the development team or the up sky You ask him how many servers does it take to install your application and the answer comes back and says well We can do it all on one And when you start diving into the architecture you realize whoops There's a propriety protocol between the fat line and the back end that needs this application to function And so by just asking this concept on introducing this concept concept that you've got a network and Through an IP protocol you need to communicate to a second Network the team starts thinking about that from a roadmap perspective says what is the Challenges at pulling my application apart and pulling the application apart into a front end an application and a database model is Extremely important in this loud world because not only do you want to secure the front end? You also want to become increasingly more secure in the middle and at the back end as you store data You will need all of those things to convince your customer that you are good enough to do to earn their business security scanning Very often in legacy applications is optional But in any one of our big enterprises we've got Really good security teams and those security teams will find a new world in the open stack Domain in the cloud development model that says developers are eager to work with them I am working with some teams that within five minutes from a security scan being done They will have the code written for the vulnerability shown That is security on steroids, but you've got to inject it at a place. You've got to show a team What is the exposure on the application? At the operating domain you need to think of data center Cloud platform and application. Let's look at those certifications certifications at a data center level we come out of a SAS 70 and we still still have data centers that only professing I am SAS 70 certified. What does that mean? It means that that data center has got a certain amount of controls That guarantee how they operate that model of SAS 70 is moving to SAS AE16 So we have a lot more fun in an SAS 16 or it versus SAS 70 It's much more broader. It's much more applicable to the customer But as you advertise your product you need to ask the question that says is my data center SAS 70 certified Or is it SAS AE16 and that's a beginning point because you can't go to the market You can't go to your customer unless you have a certain guarantee of compliance And secondly that teams working with the product is quite often traditional operations People that's extremely dependable. They are predictable They are process driven and they are slow by design And as we move into the cloud paradigm that traditional operations team needs to adopt a model of moving to a hosted Operations team and we'll get to DevOps in a bit But hosted operations mean is they don't support just one set of servers There's not very much a zoning in on to specific products But as a general tool set supporting multiple applications or multiple clients And so there's hosted operations team starting to put the client first and The system second and that's a characteristic when we look at the cloud is the customer comes first You retain the customer you make money you retain the customer you retain your job inside of the enterprise But if you don't you move on Right, so let's look at the maturity as we grow now And so this first band often materializes in the road map at roadmap roped map activities Sometimes it will take six months. Sometimes it will take a year And you can only move as fast as what your organizational capabilities are I've seen two different models in our people speed it up one It's looking at the talent inside of your organization that wants to tackle these new products. It's somebody that's hired with an agile Ability maybe have not operated in it But that person will jump in and start developing or start coding for these new practices The second one is hire somebody with this kind of experience Having a good hire on your team that understand agile that understand cloud understand multi-tenant It's a quick boost of lifting your product into this realm Cloud ready at the business domain is now looking at a standardized cloud contract, but for one customer across all products, so We quite often have business units and every business unit may have 10 or 20 applications Think at this level of creating a business unit agreement that can cover all of those applications Don't think of everything for everybody at this point in time, but start grouping where it makes sense SLAs still stay at 99.5 percent, but offer additional guarantees, maybe it's a 99.9 or maybe it's selling dr or An additional service to get from 99.5 to a better agreement most customers will say 99.5 is okay for non-critical Applications, but I want more for critical to start thinking from a sales perspective from a product marketing perspective How do I add specific services, but as a paid engagement very real? And then at a at a service agreement from a common service offer different bands of services For instance a platinum platinum level service agreement now the customer comes to you You've got a product. It's not just on-premise anymore. It runs in a cloud model very slowly But those customers are often the one that you need you've got the relationship And they willing to invest in you at becoming cloud optimized, but they want something spatial So you're gonna set up something special for them in the technology domain Absolutely start thinking now about multiple clients whip and device specific Connecting through a common API having the common API layer is one of the first things to achieve in the technology domain Because that common API layer will also be the one in a cloud optimized platform That will be your first task at elasticity scaling on demand But it cannot do it if it's proprietary protocols Think definitely at a three tier architecture not just two tier at this point in time and Everything should be encrypted communications to the back end should be encrypted and communications at the back end should be encrypted, but you may say I will store Data encrypted at rest or content, but maybe my database is not encrypted to this point in time Those are things you've got control over or you maybe say is I want my database my search engine all of my Content to be encrypted and that's great. Just keep in mind. It will take a long time to do all of that So decided that level of encryption. What is important? And now at this level you start introducing vulnerability scanning take the OWASP top 10 and See from the outside of what is the vulnerabilities of my system and start thinking how do you bring that quickly into the development process phase one? Or cloud friendly is knowing where I'm standing Cloud ready is Introducing what I'm knowing inside of my development process in the operating domain SSAA 16 So as 70 is not an option from my perspective in the industry today SSAA 16 as you've got a test to your capabilities, but then you should also be measured or audited against it Now you can say as I have an SSAA 16 for my hosting center my data center And this is where you should start thinking about I have an SSAA 16 for my cloud operating system for my open stack deployment meaning that my open stack guys will also be Measures from a security perspective because at the end of the day, it's a layered cake You can't just have an SSAA 16 at the application, but things underneath it is not healthy And then from a DevOps perspective is now we touching on what is that and DevOps is a team in a nutshell integrated with agile development scrum and sprints So now we're looking at cloud ready. You don't find the terminology of waterfall anymore You only find agile you only find scrum you only find scrum sprints and you find the ability to put people into those work sessions All right, and eventually if you get all of that, right? You're gonna move into a cloud optimized model standard cloud contracts shared among amongst all application families if you can have one and your general counsel The customers buy one product from you when they buy a second product the same thing is true as they want to see the same contract as a matter of fact I have found that customers are often lenient at Expecting things in the contract that makes sense to them They don't want the whole enchilada If I work with a lawyer from a customer perspective that puts a 500 page document to me My first meeting will be as let's let me let's see what you are looking for There is a perception and clout is that you're gonna consume a server at a lower cost because we've got the benefits of multi-tenancy that comes at a rational Behavior at a contract level So put in that contract. What is reasonable to be expect for that customer? based in breed SLAs 99.95% and now we can look it from a technology perspective and says how do I use my autonomous zones? How do I use multiple sets of applications and I can go wild at meeting that money? 9.5 I can go wild at monitoring it But basically what I do is I'm stating that I've got a based in breed SLA now I have not seen many customers or many companies that says based in breed is four nines or five nines So you're looking at three and a half nines. That's kind of where the industry has said is three and a half nines I can live with so many minutes of downtime for my service in this cloud model and then custom services agreement so The reality is unfortunate fortunately like this way is this you want to standardize as much as possible But you will have specific customer or specific business groups that is spending enormous amounts of money on your software And so those cases is you're gonna go all out at making sure that your team from a services perspective Is integrated with the customer team and so we come back with a custom model But it is absolutely revenue driven at the technology domain. We now have elastic APIs that can scale on demand We don't just have scalability, but we have multi-dimensional scalability. We can't just scale Horizontal, but we want to square scale vertical as well We want to be able to take one customer's workload and move it to a certain set of database Service if my platform of database service can't handle my collective load So we're not just looking at elasticity in a linear manner We're looking at in a multi-dimensional model and we go full-out on security IDS IDP firewalls all over the show Security monitoring all integrated into the development process. You will know it works and when you see the Scanning email come out and 15 minutes later. You see the response come out from the development team That says this is inside of the next Sprint this is inside of the next release. I've tested it. It will be in production within a week And at the operating domain SSI is 16 now on all three levels at the data center At the cloud operating system at OpenStack level and at the DevOps level I am fortunate to work with HP was one of the best security teams in that in in OpenStack world If I look at their SSI is 16 their security models in HP cloud services It is just a pleasure to work with them. They take it off my plate But I can guarantee my customers is not only is our data center secure But cloud is secure as well as the applications running on that cloud Okay, so keep in mind again the pattern the pattern is a framework It is a maturity model. So the intention of the model is to give you a starting point It'll take you from the starting point into a final in-state But it is a model that you can explain in interactions with your developers with your sales teams with your legal With your marketing teams with your customers. That makes sense. There's a lot more detail behind this as you go through the process and Again as you do an architectural review of an application. That's my choice to start with that I don't typically start with a business perspective Most cases I've seen the business far ahead of the technology teams That says I see this is a way to to compete better with my customer I see this is a way to make more money So the technology teams comes up and says how do I fulfill this business vision? But doing an architectural review gives you a good context on that application that you can step through this in a roadmap perspective one of the questions I often get asked is how long does it take I Love one of the the triangles of us in the keynote fast cost speed and All we have today is fast fast and fast So that's the answer do it fast fast and fast The side where you want to start whether it's your people or your technology, but acting urgency I'm going to dive into two of these two mains a little bit deeper The first one is going to be in the compliance model And I've detected a slight change in the compliance model as we move from a SAS 70 model That's barely sufficient for the application Into especially enterprises that's adopting cloud platforms and the enterprise again has got established security teams They've got established security policies and they expect people to follow their guidance because their jobs is to protect us in the enterprise from bad things to happen with us and So they don't start with an application They start today with the unified complains compliance framework. What is a u.s. UCF a ucf in a nutshell is security guys that understand all of the security frameworks they understand SS ae 16s they understand HEPA and FedRAMP and PCI and Whatever you want to call it and so they recognize that there is common controls across all of those frameworks The clever security team also understands that not all of these controls is applicable to a cloud maturity model of cloud ready They will expect less at cloud ready because you can't deliver all of it They will expect more at crowd friendly and they will expect all of it at cloud optimized But a UCF is a grouping of controls that will feed the compliance frameworks So if you want to deal with the federal government you perceive your FedRAMP certification It's going to be a very specific set of controls if you are medical insurance and you want to go for EPA That's what the UCF will provide. So again, it's turned around not SAS 70 and in application It's now UCF and all of the frameworks below that but at least I have the following control objectives inside of your application When we look at hosting that cloud application whether it's from a with a partner or inside of our own data centers Be sure it's secure highly available with global coverage There's more than enough options in the world one of the characteristics in the cloud world as well as In application does not stay within country borders with before you know it is another country another team that wants to Consume it. So when you start your planning choose partners with that kind of coverage Make sure communications to the applications data in motion and data at rest There are a set of controls stating what those needs to be and they are measured a customer wants to know that in a multi system multi-tenant system that there is Secure account management principles and so you logically have to explain I've seen one very good example of one of the products I've worked with this that the web layer is fully multi-tenant But in an application and database layer It is fully single tenant and that application is busy moving into a maturity model of optimized But today they can't but at a web layer. They are introducing account management principles Everybody logs into the same interface and as you log in you get zoned into your logical tenant and then into your specific infrastructure in the back end data privacy Make sure you sign up and do safe harbor and international organizations that comes with this Make sure you have disaster recovery and backups from day one in my previous model. I explained that they are Specific RPOs and RTOs could be a sellable service. It takes a customer from bronze to platinum So you got to think of how do you pay for dr? Meaning you've got to think of how do you charge money for dr? But whether your customers buy it or not you cannot afford moving into the cloud Unless you have dr and backups from day one It may be a tabletop dr exercise on day one that moves into eventually a warm Eventually a multi-regional model But have it on day one and then lastly security monitoring and management as you go through the the sales process as you look through the Providing of the service the auditor of your customer or your internal audit team will ask you for the evidence In each one of these controls Okay, so let's finish this discussion on the DevOps model. I'm always amazed Every conference every session that I attend on this topic. I would ask the presenters What do you think where is DevOps? Is it part of R&D or is it part of operations? And it's quite predictable depending on from where that person comes from if he comes out of a software development Yep, his answer is very predictable. It's part of the R&D team And I've seen the operations guys with equal amounts of passion really intelligent guys on their field Aesthetic exactly the same as is yep. It's part of the operations team So I'm not gonna try and solve that Problem today, but I'm gonna tell you what it looks like when it works So DevOps is a scrum for operations that is integrated with the development teams They are engineers with tight feedback loops that are part of daily stand-ups This is one of the most important things on the DevOps team is that ability of that person to see immediately when something will go wrong and Feed it back into the software development lifecycle the developers love that kind of talent because they don't have to worry They know somebody's gonna catch it even though quality starts at the first test You write at the first line of code you like you write you've got that Integrated feedback loop and they are involved with planning activities in iterations alongside the developers all school Means that I receive my opera operational requirements after the code is written. No in new school The operations team is integrated into the planning they decide what some of these tissue sizes are They work with those developers at making it real. What does DevOps do? They are absolutely masters of application Deployment they own the tools and the procedures to move code through environments From a security perspective at some point in time You need to have segregation segregation of duties between development environments and production Your customers will expect that from you in a smaller shop The architect will do everything but as you grow and revenue flows with your product either inside of the enterprise or outside Security teams will ask is who's what's your check and balance there? They provide and use monitoring tools again that generate continuous feedback And so lastly let's look at the ironing qualities It could be a developer with an interest in operations or In operations guy that can code All right, this is as clear as that and so you apply it to your specific team is specific circumstances But it's one of those two teams one of those two guys. They are adaptable and creative They do not work against the deaf team, but with them One of the biggest things you can do as you mature in the cloud development in the deploying open stack is to find people That's eager to work with the development teams. There's no more us and them break down the boundaries Break down the walls in the cubes and put the ops guy and the developer in the same queue cube Maybe get them two different computers, but if you want to stimulate that behavior experts in scripting languages bash pull python Bonus in my world is Ruby groovy and our long so you get those kind of skill sets bring them in Very strong Linux background There is a clear movement from Microsoft Windows as the the key enterprise operating system Into a Linux based model and then tools wise Nagios puppet and chef Okay, so what I've done in this presentation if I sketch the The reality of our world will all can be excited about open stack But as we move from reality into current environment think of this model and Documented further inside of your world cloud friendly Moving to cloud ready Moving to cloud optimized. Thank you We are out of time for the session, so I'm not gonna open up the floor for questions But if anybody wants to ask questions afterwards, I'll be on the side