In this article we will provide a hands-on guide to building your very first operator in Ansible. Using the Operator SDK we will learn how to create boilerplate code, build and deploy an operator.
This article is part of a series that will walk you through understanding and building operators in Go or Ansible end-to-end.
In this article we will provide a hands-on guide to integrating your already built Operator with the Operator Lifecycle Manager (OLM). Using the Operator SDK and OPM tool we will create the application manifests and images so your application Operator can be managed through OLM.
This article is part of a series that will walk you through understanding and building operators in Go or Ansible end-to-end.
In this article we will introduce the concept of Operators, the Operator Framework and Operator Lifecycle Management. This article is part of a series that will walk you through understanding and building operators in Go or Ansible end-to-end.
First, what exactly is an Operator?
An Operator is a method of packaging, deploying and managing a Kubernetes application.
source: https://coreos.com/operators/
Or simply, it is the application that can deploy itself, manage itself and update itself. Welcome to the brave new world, where we don’t spend time doing repetitive manually tasks, but rather put our knowledge into software so it can do it for us, better.
In this article we will provide a hands-on guide to building your very first operator in Go. Using the Operator SDK we will learn how to create boilerplate code, build and deploy an operator.
This article is part of a series that will walk you through understanding and building operators in Go or Ansible end-to-end.
In this article we start a new journey, automated infrastructure in the on-premise datacenter. We will deploy OpenShift 4.2 on OpenStack. As I am sure you are aware, OpenShift is Red Hat’s enterprise kubernetes platform. Kubernetes is of course the brains but by itself is not a platform. OpenShift brings with kubernetes, monitoring, aggregate logging, container registry, security, automated deployment/upgrade, developer experience, huge middleware tooling built around JBoss, serverless frameworks, ISTIO (service mesh), CI/CD integration and the key word “ENTERPRISE“.
Java has been around a really, really long time. Certainly it continues to evolve and has evolved. Java has always been a “can do anything” programming language. It has more frameworks and middleware than there are stars in the sky. It is portable anywhere and of course probably 8 out of 10 developers today know Java to some degree. Given all of this though is Java the path forward?
Looking forward I think the clear trend is microservices and beyond. Therefore the question is a lot simpler, is Java the best path forward for microservices?
Often a lot of people seem to confuse Kubernetes with OpenShift or a platform-as-a-service (PaaS). Kubernetes is of course on it’s own, not. It is an orchestration layer or technology for containers but a lot is missing to really call it a platform. OpenShift is Red Hat enterprise Kubernetes platform. It contains Kubernetes but also a whole lot more which make it a true platform. So which is right for you? It depends a lot on your requirements and what you are trying to achieve. The purpose of this article is to setup an environment for running a workshop that compares the Kubernetes experience with OpenShift in order to gain more insight and understanding in what you may actually need. Many people sit down with slides or at a whiteboard, but I really find that is not adequate and you really need to experience it, first hand.
In this article we will look at the OpenShift service broker, understand how to integrate external services into OpenShift and even create a custom broker. First before we begin a big thanks to Marek Jelen and Paul Morie, Red Hatters who both helped me understand the service broker in greater detail.
Obviously if you are reading this article you already understand microservices, containers and why it is all so incredible awesome on OpenShift. Of course everything should be in a container but unfortunately it is going to take a while to get there. As we start dissecting and breaking down the monolithic architectures of the past, likely there will be a mix of lightweight services running in containers on OpenShift and other more heavy services (databases, ESBs, etc) running outside. In addition while the service catalog in OpenShift is vast, even allowing you to add your own custom services for anything that can run in OpenShift as-a-container using a template, there will be the need, especially with public cloud to connect to external services. Both of these use cases, on-premise external services and off-premise cloud services really made it obvious that a service broker and more robust service catalog was needed. Originally OpenShift did not have a service broker so you couldn’t easily consume external services. All that existed was the service catalog and templates, so every service had to be a container running on OpenShift. Thankfully other companies also saw a need for an open service abstraction and the Open Service Broker API was born as an opensource project.
In this article we will discuss the benefits containers bring to business continuance, reveal concepts for applying containers to disaster recovery and of course show disaster recovery of a live database between production and DR OpenShift environments. Business continuance of course is all about maintaining critical business functions, during and after a disaster has occurred. Business continuance defines two main criteria: recovery point objective (RPO) and recovery time objective (RTO). RPO amounts to how much data loss is tolerable and RTO how quickly services can be restored when a disaster occurs. Disaster recovery outlines the processes as well as technology for how an organization responds to a disaster. Disaster recovery can be viewed as the implementation of RPO and RTO. Most organizations today have DR capabilities but there many challenges.
I would take these challenges even further and suggest that for many organizations business continuance and DR is nothing more than a false safety net. It costs a fortune and in the event of a true disaster probably won’t be able to deliver RPO and RTO for all critical applications. How could it when DR is not part of the continuous deployment pipeline and being tested with each application update? How could it with the level of complexity and scale that exists today and not 100% automation?
In this article we will explore why you should consider tackling IaaS and PaaS together. Many organizations gave up on OpenStack during it’s hype phase, but in my view it is time to reconsider the IaaS strategy. Two main factors are really pushing a re-emergence of interest in OpenStack and that is containers and cloud.
Containers require very flexible, software-defined infrastructure and are changing the application landscape fast. Remember when we had the discussions about pets vs cattle? The issue with OpenStack during it’s hype phase was that the workloads simply didn’t exist within most organizations, but now containers are changing that, from a platform perspective. Containers need to be orchestrated and the industry has settled in on Kubernetes for that purpose. In order to run Kubernetes you need quite a lot of flexibility at scale on the infrastructure level. You must be able to provide solid Software Defined Networking, Compute, Storage, Load Balancing, DNS, Authentication, Orchestration, basically everything and do so at a click of the button. Yeah we can all do that, right.
If we think about IT, there are two types of personas. Those that feel IT is generic, 80% is good enough and for them, it is a light switch: on or off. This persona has no reason whatsoever to deal with IaaS and should just go to the public cloud, if not already there. In other words, OpenStack makes no sense. The other persona feel IT adds compelling value to their business and going beyond 80% provides them with distinct business advantages. Anyone can go to public cloud but if you can turn IT into a competitive advantage then there may actually be a purpose for it. Unfortunately with the way many organizations go about IT today, it is not really viable, unless something dramatic happens. This brings me back to OpenStack. It is the only way an organization can provide the capabilities a public cloud offers while also matching price, performance and providing a competitive advantage. If we cannot achieve the flexibility of public cloud, the consumption model, the cost effectiveness and provide compelling business advantage then we ought to just give up right?
I also find it interesting that some organizations, even those that started in the public cloud are starting to see value in build-your-own. Dropbox for example, originally started using AWS and S3. Over last few years they built their own object storage solution, one that provided more value and saved 75 million over two years. They also did so with a fairly small team. I certainly am not advocating for doing everything yourself, I am just saying that we need to make a decision, does IT provide compelling business value? Can you do it for your business, better than the generic level playing field known as public cloud? If so, you really ought to be looking into OpenStack and using momentum behind containers to bring about real change.
