As organisations change the way they create and deliver the software that underpins their business, a new and better method of getting ideas into code and into production is required. Approaches such as Agile, Continuous Integration and Continuous Delivery all figure into this equation—as does the cloud.
Many organisations have built “their” platform—only to discover that it can be hard to maintain and difficult to extend across multiple cloud providers. Another element is the desire to gain the ideas of the “best and brightest” in the industry as to how software should be built and operated—and automate all of that into a common framework.
A lot of industry focus is around what this Platform as a Service should look like, what it should do, and how it fits into the IT ecosystem. Add to this the rapid adoption of cloud technology, and the adoption of new development languages and frameworks and you have what only can be described as “interesting times”.
In this week’s episode, Simon shares insights on why organisations want to use Platform-as-a-Service, and a more detailed tour of Pivotal CF and its components. This includes some of the high level ideas behind the platform, why it is built the way it is—and looking “under the covers” as to the major components that make up the platform.
PLAY EPISODE #2
- Subscribe to this feed
- Find more episodes of All Things Pivotal podcast
- Feedback: firstname.lastname@example.org
- Links Referred to in the Show:
- An example of the scaling speed in Cloud Foundry.
Welcome to the Pivotal Software Podcast, the podcast at the intersection of Agile, cloud and big data. Stay tuned for regular updates, technical deep dives, architecture discussions and interviews. Please share your feedback with us by emailing email@example.com.
Hello everyone and welcome back to the Pivotal Software Podcast, fantastic to have you back. My name’s Simon Elisha, CTO and Senior Manager of Field Engineering here at Pivotal in Australia and New Zealand.
This is episode number two. We’re going to be talking about why customers would want to use Cloud Foundry. Great to have you here and we’re going to take a little bit more of a deep dive into Cloud Foundry. Not super deep into the technical levels, we’re kind of taking it one level at a time. This one’s going to go a little deeper than we spoke about in the previous episode.
What do customers do with something like Cloud Foundry? Cloud Foundry is platform as a service. What does that mean? Really customers are looking to build new applications and when they build new applications they want them to scale so they can grow over time. They want to be easy to deploy, so they don’t cost a lot to implement and run. They want to be easy to operate and easy to update.
Now these things sound simple when you talk about them, but if you’ve ever worked in a large organization or with complicated software you’ll know that getting a new release out can be a nightmare. Operating it can be expensive, some of the architecture can be brutal.
The idea of platform as a service is to take all the learning and all the understanding we have about building massively scalable architectures and roll that in to a platform that does it for you. Except from a developer’s perspective you worrying about feature function, you’re not worrying about things like update ability, operational efficiency, scalability, et cetera.
We also need to take care of things like high-availability and resilience. Again, we don’t have to build that into the application every time. If there are patterns that we can use and capabilities we could take advantage of, that will do that on our behalf. We also want flexibility in our development environment. It’s interesting to see organizations taking a far more polyglot view of development languages and the way they develop applications.
Things like Java, Ruby, Golang, Node.js, Python, et cetera are really popular language sets. As we move into an age of micro services, something will speak about later, there is even more opportunity to use the right tool for the right job. The right tool means the right language to deliver a particular capability or service or function that can be done particularly efficiency using that particular language.
It’s interesting, once you break out of a mono cultural or single view of how to develop software you see many different ways to solve many different problems. This can open your mind and open the possibilities to you in terms of how you build things. Organizations also want to have choice in to where they locate their particular workloads.
Someone will run them on premises, others want to run it in public cloud. Some want to run it on internal cloud now in and into the future. There’s a lot of choice in terms of where things could run, which providers they’re going to use and what they might do in the future. It’s always a sort of a concept that people look for is to be able to have a choice. People want to have their options open, they want to choose.
By leveraging a platform as a service that is controlled by the customer, they can then choose where the applications are deployed and more important deployed them in a consistent and coherent fashion across multiple different providers. They also want to be able to deploy their code easily and consume services easily.
Again, we live in a services oriented world. Things like queues, databases, memory caches, et cetera, want to be able to grab them and use them very easily with a minimum of fuss, testing and integration work. Now, Cloud Foundry provides the abstraction and automation for deploying apps, as well as where they run.
It provides a really interesting sort of capabilities from a development perspective and a developer community perspective and also a really interesting set of capabilities from an operator or operations group perspective as well. How does it do this?
Pivotal Cloud Foundry’s broken up into three areas. It has elastic runtime service, which is a complete, scalable runtime environment. It’s extensible to support most modern frameworks and languages running on Linux. It allows you to deploy applications that have built-in services that you can bind to automatically.
It means you can use a service broker or services that are running on the platform themselves to consume these services in real-time. This is used in both development, test and production and allows you to move through those stages in a very seamless and straightforward fashion.
Then there’s the Pivotal CF Operations Manager and this is actually the industry’s first turn key enterprise PaaS Management platform with infrastructure as a service integration. What this allows you to do is to manage that infrastructure as a service layout that underpin the platform as a service. This is where you get that choice piece, this is where you get the control piece.
By choosing the platform that you’re operating on, you’re not making any decisions about that provider that you’re running your code on. In fact you have complete flexibility and complete choice. Then there are the Pivotal services, which are add-ons such as Pivotal HD, Pivotal RabbitMQ, My SQL, et cetera that allow you to do automatic application binding and service provisioning. I’ll talk a little bit more about that shortly.
Let’s break it Down in terms of what we actually do day-to-day. Let’s take deploying an application for example. In Cloud Foundry this becomes a simple one command deploy option. CF space Push, that’s the command. Grabs the current application, looks at the manifest and deploys application for you.
It does a whole lot of cool stuff behind the scenes we can dive more deeply into that in the future. Basically, it allows you to plug into your IDE or your tool chain and basically choose the size of the instances that you want to deploy to, the number of instances and it does the rest.
Now this includes things like downloading dependencies, runtimes, libraries using something called buildpacks, we’ll get into detail around that that explain how different types of applications should be built and deployed. It does all that for you, so it make sure that everything is collected all the components are correct and away it goes.
They all bind to a domain name automatically for you, so it make sure that it registers and it can receive traffic. It will also do the load balancing between instances for you automatically. It also has some super cool capabilities in terms of being able to change an application’s binding at runtime, introduce new versions, do things like AB testing et cetera that are definitely worthy of further conversation.
Of course you could change the scale of an app at anytime. You can add instances or remove instances. It literally takes seconds because you’re not waiting for VMs to spin up because the Cloud Foundry architecture is built using containers. Now this is a very important distinction and, again, change the dynamics and timeframes of scaling activities for your application.
In your traditional VM based environment, when you’re waiting for a VM to start up it can take anything from two minutes to five minutes. Depending on the infrastructure of the service provider that sure using your mileage may vary but it can take a little while to do that.
It’s interesting, coming from a background that I do I’ve been around for a while now for me six weeks to get a server was good timing. That was considered fast and when I moved into the cloud world and could get them in minutes I was amazed, this was heaven.
I remember speaking to some developers recently of the younger generation and they were complaining to me that it took too long to get a server using the cloud. I thought wow how perceptions have changed. I said, it only takes five minutes, but it’s five minutes. It’s too long, it needs to be like in a second.
One of the nice things about scaling and Cloud Foundry is that it is literally seconds. In fact, there are some very cool videos. I might try and link to one in the show notes that show you how quickly you can scale up and down using a container based technology.
Now what about from operational side of things, operating our applications? Is very often forgotten detail and certainly an expense. If you think about the lifecycle of an application are over its lifetime, there’s a lot of focus and attention and joy around the development process, but most of the cost is actually in the operational piece.
In fact, if you look at most IT operations or IT departments, 70 to 80% of their budget is consumed by just keeping the lights on, business as usual activity. This is because everyone builds applications differently and there’s sort of different components to support and different things to manage and availability in logging, et cetera, so we try and hide a lot of that and make a lot of that much easier in the Cloud Foundry context.
Some of the fundamentals are handled automatically. A really good example is automated logging, the ability to send logs to a central location, see them in real-time and aggregate them easily. So built into Cloud Foundry is the ability to get all the logs from all the containers that are running and send them into some sort of centralized location for analysis and for activity and for management.. You can also get the individual ones as well as you like. There’s no effort required to do this, it’s just there, which is fantastic and gets you way ahead of the game.
We spoke about high availability and the ability to be resilient and there are four levels of high availability that are built into Pivotal Cloud Foundry. Firstly, there is the concept of availability zones. These need to be sensibly defined availability zones that live on different resource pools.
In the V center world you may choose one V center resource pool for one availability zone and another one in the second availability zone. You get to choose where these availability zones are and you can imagine how you can make them quite diverse and quite flexible.
Once you’ve chosen those availability zones you could figure your Pivotal Cloud Foundry deployment so that the nodes upon which your application runs is called DEAs are created across those availability zones. This means that you get even distribution across availability zones and they are balanced automatically.
What this means is if you lose one of the availability zones you still have the instances up and serving traffic. That’s one level of availability and a really fundamental and important one to have. Of course, if something happens and you use an application instance, maybe it’s a bug in the application or AZ goes down or a node goes down, you need the system to compensate to take over from there.
Restarting new instances is what’s important. This is where something called the elastic runtime manager becomes really important. The health manager is constantly looking at the state of the system and in particular it’s looking at how many instances of each application are running across all of the DEAs.
It knows how to be an application should be. Maybe you set up an application said each should have 10 instances running. It will always be checking to say, hey, are the 10 instances running. If it sees a deviation from that state, it will start to fix it and talk to something called the cloud controller.
Clock controller is kind of like the brains of the operation. It’ll say, hey, cloud controller, the number of instances for this application is not correct please rectify that and the cloud controller will do that automatically. That gives you immense power there as well.
Of course, Cloud Foundry itself is software so there needs to be constant monitoring of the processes that make up itself, Cloud Foundry itself and automatically restart and repair those components. It does that automatically for you so you don’t have to worry about it. Basically think of it as a self-healing environment. That means that the platform is running efficiently as much as the application’s running efficiently.
Finally, the fourth thing, we need to monitor the underlying VMs that holds the platforms and apps and automatically replace those failed VMs and those failed apps. In the cloud we often talk about the fact that when things get big things will fail on a regular basis, you need to design and expect failure so we do.
Again, Cloud Foundry assumes the components will disappear, the infrastructure as a service layer, but we can replace them very quickly in an on demand way. The platform is a service component, Cloud Foundry, will do that for you.
It will go and say hey this VM that’s hosting this DEA that’s hosting this set of applications has gone away for some reason, it’s taken a bit of a break. It’s time for a lie down. I will spin up a new instance. I’ll load the software on and I’ll get these going again.
You can imagine how powerful this is from an availability perspective given that if you’ve written your software in a stateless fashion, you don’t have to worry about any of this componentry, it just happens for you, you get this availability. Also on the operations side operators have full control over where the cloud applications are deployed, the size of their deployment and the nature of the nodes they deployed to.
Now this can be point and click through a GUI or through a command line and uses the concept of a cloud provider interface or CPI to allow infrastructure as a service neutrality. What this means is that you operate in the same way, whether you’re running on VMware VSphere, AWS, Google Platform, Open Stack, et cetera.
The key here is that as the infrastructure as a service market becomes more competitive and changes over time you can run the same platform and have total choice and portability as well as operational consistency. This becomes important as you see the different sort of infrastructures the service provider delivering, different instance types or different price points or maybe different geographic locations that suit your particular application.
From a deployment and operation perspective you’re still using exactly the same platform that you used before, you’re just deploying to a different provider in a particular region. Think about the efficiency and the consistency that that gives you while it’s allowing you to take advantage of the flexibility and competitive tension that’s going on in that marketplace.
We often see prices being dropped dramatically and organizations releasing one feature and function and they won’t release the other one. It is sort of like how do you pick a winner, well you don’t have to. You pick a platform and deploy upon multiple providers that suit the best purpose at the time for what you’re trying to do.
Let’s round it out with a bit of the discussion around services and service binding. In architecture, we decouple applications and try to consume services as much as possible. For removing us from this sort of big ball of tar, this big monolithic code base to little services they can talk to one another. We try reuse maybe public services or internal services we provide for ourselves so that we can make change more easily, we can be more flexible and of course we can be more scalable.
Cloud Foundry enables you to make both the discovery of and binding to these services really easily, as well as allowing you to run up your own use service instances dynamically on the platform itself. We’re going to spend a whole episode on this some time but I want to sort of give you two use cases to give you a bit of a taste of what this capability lets you do.
Imagine you can spin up an instance of Rabbit MQ, which is a multi- protocol message broker, very common in a lot of scalable applications. You could spin this up instantly with zero configuration and have it automatically bind to the application using proper credentials that are not hardcoded into your app.
This makes it super fast for a developer to develop, to test and to go into production and to move through those steps and a very consistent fashion. Because the configuration mechanism is done in a more dynamic way, we’ll talk about how that’s done in that next episode, you don’t have to worry about hardcoding things in application or configuration files that are left behind, et cetera, which can get really complicated, again, make it very simple.
It should work the same from laptop to server to test production and this kind of instant access to a service makes it very easy. There are services that run on the Pivotal Cloud Foundry platform, so they’re running within the platform as a service and they can be spun up immediately, but you can also access the service that exists outside of the platform via what’s called a service broker.
For example, a corporate data link or some other data source, you can get there via a simple consistent interface, that again, manages credentials, access, communication et cetera. It just means you can start to consume services that are sort of fixed into place if you like or existing corporate assets through an API very, very effectively and provide the developer community access to a much richer set of sources of information.
Again, there’s way more to this but that’s probably enough for now. Where are we running to? What can people actually do with this? People can develop and test applications way faster than they ever have before. They can have what they deploy to production work as reliably as when they developed it locally, irrespective of where the app is deployed to. If it’s deployed on premises, if this deployed on the cloud or hybrid of the two, it works the same.
It’s interesting, often when I talk to developers the frustration they feel and they say it worked on my laptop but it doesn’t work on when I deploy it in production or the operations folks would say those crazy developers, they don’t know how to deploy a scalable system or what it means to operationalize for production. This is kind of bringing the two together of making it far more efficient and effective.
I hope that was useful. A bit of a start. In future episodes we’ll go more under the covers of Cloud Foundry to see how it ticks and see what you can do with it but until then, let others know. We’d love to hear your feedback, firstname.lastname@example.org
Please do tell others about the podcast. We’re very new and we’re very fresh, so we want to have a new set of listeners and understand what you as a listener community want to hear. Until then, I wish you well and keep on building.
Thanks for listening to the Pivotal Software Podcast. If you enjoyed this episode, please share it with others. We love hearing your feedback, so please send any comments or suggestions to email@example.com.
About the Author
Simon Elisha is CTO & Senior Manager of Field Engineering for Australia & New Zealand at Pivotal. With over 24 years industry experience in everything from Mainframes to the latest Cloud architectures - Simon brings a refreshing and insightful view of the business value of IT. Passionate about technology, he is a pragmatist who looks for the best solution to the task at hand. He has held roles at EDS, PricewaterhouseCoopers, VERITAS Software, Hitachi Data Systems, Cisco Systems and Amazon Web Services.More Content by Simon Elisha