Last week I was writing down why enterprises should use OpenShift as the foundation for building their enterprise platform and I wrote down following points.
When building an internal Microservices platform for an organization Kubernetes is just the foundation you need many more tools and workflows to build a platform. OpenShift is a Kubernetes superset combining over 200 open source projects into a fully integrated solution with strong focus on a developer experience, operational capabilities, monitoring, and management with strong and secure defaults. Some of the open source projects include Istio, Argo, Prometheus, Jaeger, ELK, Keycloak,etc. OpenShift is support Kubernetes along many other supported components.
OpenShift is secure by default.
CoreOS container Operating System. Reduce surface area for attacks.
You can define upgrade windows and schedule them
OpenShift is certified with over 200+ ISVs. These include Finacle, CloudEra, MongoDB, SAS Viya, and many other.
OpenShift is available as managed cloud offering on all the three clouds – Red Hat OpenShift for AWS, Azure Red Hat OpenShift, Red Hat OpenShift Container Platform on GCP.
Allows you to manage multiple clusters through a single pane of glass
In the last few months I have given a lot of thought on the minimal technical documentation that all projects should have. I consider it essential to building a quick understanding of the project and quickly onboard new developers. These documents should be maintained in the version control just like the code. The technical documentation should sit in the same version control repository as your code.
To come up with the answer I try to find answers to following questions in context of the organization:
2020 was a difficult year for most of us, as we fought with COVID-19 and came to terms with the remote way of working. It was a year when we had a lot more time in our hands as all of us were locked in our houses with almost no travel. The things that we took for granted were taken from us and there was a constant fear of losing the loved ones.
I hope in 2021 we regain our freedom to live freely. But, this time with a sense of responsibility and awareness.
It is now little over a year since I became Chief Technology Officer (CTO) in my current organization. And, I thought it will be a good time to do a quick retrospective on the lessons learned in my first year as CTO. The journey has been tough but deeply rewarding for me. There were occasions when I thought the leadership role was not for me and I should go back to being an individual contributor. But, with support from my organization and learning (books, blogs, observation), I have started to enjoy the role and its challenges.
Before I talk about the lessons I learned, let’s look at my software engineering journey.
I decided to spend year-end holiday time reading a couple of books. I like to read books that in some way help me solve problems that I face in professional and personal life. At work because of my title and circumstances I have to play three different roles – maker, manager, multiplier.
In my current role as Chief Technology Officer (CTO), I am responsible for the engineering quality of our software delivery teams. We are an IT service organization where every now and then, we get to work with different kinds of customers in different domains and each at a different maturity level in software delivery.
One thing that I often struggle with is how to unite the individual engineering teams working for different customers with a common shared belief system that is actionable, pragmatic, and less abstract.
You may ask, isn’t that what organization values stand for? Before we answer, let’s define the three common terms: Values, Principles, and Practices.
In the last couple of years, one question that I have been often pondering is—
why it is difficult for senior leaders of an organization to work in unison and achieve great things together. While there are organizations that accomplish amazing things one after another, there are many others, where leaders cannot think beyond themselves and their self-interests.
The failure, in context of the blog, is not about an organization failing financially or collapsing in terms of business. An organization can be successful yet fail to achieve great things. This is a story that I have seen, read and observed, over the years. A new senior leader joins or an existing employee is promoted to a leadership role. They want to bring positive changes (at least they think that way) and become messiah for the organization. After a couple of years, there are only little achievements to be shown, nothing big and transformative that may have been realized or accomplished.