In a previous episode we explored some of the cool partner products available as Product Tiles within Pivotal Cloud Foundry® (PCF). This sparked some questions about how you can create your own. In this episode we explore the process for creating and releasing a Product Tile on Pivotal Cloud Foundry.
- Subscribe to the feed
- Feedback: email@example.com
- Links referred to in the show:
Welcome to the Pivotal Perspectives podcast. The podcast at the intersection of Agile, Cloud and Big Data. Stay tuned for regular updates, technical deep dives, architecture discussions and interviews. Now let’s join Pivotal’s Australia and New Zealand CTO, Simon Elisha for the Pivotal Perspectives podcast.
Hello everybody and welcome back to the podcast, great to have you back and great to be back. Speaking of being back, I am back in home base, Melbourne, Australia, so not one of those on the road podcasts, but one of those in home base. Not that I guess it really matters from a listening perspective but it matters from a creation perspective perhaps. Today’s podcast really follows on from one of a few weeks back when we spoke about some of the new partner tiles that were available in PCF. If we just step back for a minute, so in Pivotal Cloud Foundry we have the concept of product tiles and these tiles are laid to install and provide different services that run as part of your platform and are presented to your development community. The importance of these product tiles is that it means they have a completely portable, independent and useful set of components that they can use to compose their applications.
Things we include with the product are things like Redis, RabbitMQ, etc., and some of the third party ones that you can now get include Jenkins and GitLab and others as well. That podcast stirred up a bit of a question of well what do I do if I want to create my own ones? Maybe I’m selling a product into the market and I’d like it to be capable of running within PCF or I’m maybe creating an internal product that I want my developer community to access, etc. How do I go about that?
Luckily we have a handy dandy guide called the PCF Partner Guide. If you delve into this it actually talks you through the steps you need to do to create this particular product tile. What I wanted to do today was to spend a little bit of time talking about what the tile is, what it delivers and some of the steps you go through to create it, to give you a bit of a feel of what’s involved. You may think, well what’s the difference between running a tile as part of the PCF ops manager and running my application on PCF? In general you’ll run an application on PCF if it’s a Cloud Native application and it’s providing a service out to end users or it’s maybe a composition of microservices that run in that Cloud Native way. I’ve talked many times about Cloud Native so I won’t go into it right now.
Where the tiles come in is if you have products that in particular are stateful, so they store information or they are designed to run on some sort of virtualized machines or infrastructure of the service or they need to be deployed in some form of very specific clustering technique, etc. Things that you would consume that aren’t going to run on a Cloud Native platform, but you’d like to made available as part of a Cloud Native platform. Things that you would also like to be easy to manage, easy to scale and as automated as the rest of the platform. This is where the power of these product tiles comes in because it leverages the frameworks that are provided by BOSH.
I’ve spoken about BOSH before, it’s like a artificial intelligence for infrastructure management and what these tiles allow us to do is, in a structured way, create a life-cycle for these products. They can be installed, managed, scaled, updated and deleted at various points in their life-cycle just using the ops manager and using the power of BOSH. There’s no operations person going in and having to configure the particular systems themselves that may enter some customization in the GUI but other than that BOSH takes care of everything, which is pretty cool.
Let’s dive a little bit deeper into this because these aren’t real products, these are things that have to be built and supported and maintained, etc. These tiles go through a release cycle and as an end user you may only see a few steps of this release cycle, but I wanted you to understand all of them because if you’re a partner this is going to be very relevant. It really goes through four phases of release. Phase one is the alpha phase and as it sounds like, you’re doing a lot of changes, you’re refactoring code, you may not have a feature complete situation. This is really the stage in which your internal developers are consuming the tile that you’re building and just working it and making sure it’s getting to sort of a MVP stage.
Then we have the next phase which is the closed beta phase. This is where we provide this to a limited pool of users, so it’s locked off, people don’t know it exists, but a smaller community of users would be able to use it to test it out to see what’s good, what’s bad, what things need to change, etc. During the closed beta things may break, there’s no guarantee that data loss won’t take place for the service, there may be bugs, you might not be able to upgrade your tile, you might have to delete and install, etc. To be a closed beta it has to run on at least one of the IOS’s, so it could be AWS, vSphere, or OpenStack. It’s got to target the stem cell version of the latest available Pivotal ops manager and also the release notes aren’t very clear about the fact that this is a limited beta and closed beta, I should say. Should not be used for anything other than experimentation.
Once you’ve done that and gone through that process, you can then go through what’s called a public beta process. This exposes you to a much broader pool of users and let’s you get far more feedback and as we know with product development, feedback is important. In the public beta phase, you have much more confidence that further development isn’t going to break the product and you’re not going to lose any data, but you’re not making any guarantees but you’re still being a lot more quality focused there. The tile can be upgraded and this is not the final release but it’s getting reasonably close to it. Again, it has to run on at least one of the IOS’s if not more and it also upgrades of the tile do not result in any data loss or configuration loss.
The other interesting thing that we’re adding at this stage is that you, as the provider, can respond to discovery of a security flaw, a CVE or common vulnerability and exposure within a reasonable time frame. These security flaws could be vulnerabilities in your stem cell or within the components of your tile so you have to maintain that. Certainly we attempt at Pivotal to respond to all critical CVE’s within 48 hours. Once you’re in this closed beta, sorry public beta I should say, you are now in a position where you really need to be supporting the beta as well.
The final release when the champagne corks get popped and all the fun stuff happens is general availability. This is when it’s production ready, this is when you can charge money for this product if you want to and you can provide support guarantees to your customers. You have all the features that you want in the product. What this means is that the product, as well as everything else that we spoke about, can scale vertically, so it can upgrade itself to run on larger instances. You can also, if it’s appropriate, scout horizontally for higher availability, so you can have more nodes and more performance.
If appropriate the product supports zero down time deployment and also that the product installation does not require an internet connection as well. What this means is that you can run the whole application end to end as a product. There are the stages that you go through.
What’s actually in a release and what’s involved in creating these tiles? The main steps are really implementing ops manager so you can experiment with the tile experience with the ops manager. The main work you do is creating the actual tile itself using BOSH. Fortunately there is a template called the product template reference and this decomposes the definition of your product into different things. It has sets of information around meta data, versioning, the steps that should take place in terms of the creation of the actual product. It has a form properties section so it allows you to configure what properties may need to be passed into your product, so it could be some sort of naming, addressing type stuff, whole bunch of different components, there’s a whole bunch of form elements, so radio buttons, select this, etc.
Anything you need to gather information for the configuration step that will appear at the ops manager layer. These use what are called blueprints. The blueprints define anything that will eventually end up as part of the BOSH manifest, which is generated by ops manager. This really is an abstraction that then goes ahead and generates all the BOSH manifest stuff, that then gets executed by BOSH and deploys and or upgrades your product. As well as deployment upgrading your product, we have the concept of life-cycle errands. Life-cycle errands are BOSH errands or scripts that run at designated points in time during a product installation, so it can beforehand or after. Most errands that you see are after or post-installed type errands and these can do things like smoke tests, checks, database migration work, service broker registration, etc. Really the things that need to be done at the end.
The important thing is that once you build your tile, everything is taken care of by the system. It becomes this very stable, very repeatable experience which means that from an operator perspective it’s easy to bring your product into the purview of Cloud Foundry and to expose it to the development community who are developing this software on PCF. They would see these services as part of the marketplace that’s exposed to them and they can consume them on demand. When it comes to building the tile as well, there are example tiles out there, so you have an example that you can use, an example product tile so you can build off that, I should say, as a starting point and get right into it and start experimenting.
A pretty neat and easy way to expose an existing product that you might have that you want to bring to market in a different way, that is providing it as part of a cloud native platform. If you go through this process, it’s a easy way to make that happen. I hope that’s been useful and a bit of a follow up from our previous discussion about some of those third party service tiles. There will be many more of them over time and now you know how they’re made and how you can make your own as well. Look forward to you joining me next time and until then keep on building.
Thanks for listening to the Pivotal Perspectives podcast with Simon Elisha. We trust you’ve enjoyed it and ask that you share it with other people who may also be interested. We’d love to hear your feedback so please send any comments or suggestions to firstname.lastname@example.org. We look forward to having you join us next time on the Pivotal Perspectives podcast.
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