I have finally taken the time get my thoughts organized and point some points together, about how I think cloud-native systems should be build: The Three Holy Grails of DevOps.
Practically none of the points I make are new or revolutionary. Quite to the contrary, I am still searching for publications that support the individual corollaries where they are missing today.
Therefore please take this document less as a revelation, and more as a personal manifest.
Establishing DevOps is a change in culture. It is all about trust, personal empowerment and cooperating on a larger goal.
There is neither such a thing as a DevOps-Engineer nor a DevOps team (and neither is there a Full-Stack Developer, but that is a story for another day).
But there are technical and organizational steps that help to improve the effectiveness of your organization and the quality of the services you provide.
This is my adpation of https://github.com/drduh/YubiKey-Guide
Here I skip the machine setup covery by Dr. Duh. The short of it is: you need a machine with a current kernal that is disconnecte from the network.
Below are my choices and changes. This is even more opinionated than his document.
Creating Keys Setup the environment:
$ export GNUPGHOME=$(mktemp -d) $ wget -O $GNUPGHOME/gpg.conf https://raw.githubusercontent.com/drduh/config/master/gpg.conf Generate a Pin $ tr -dc '[:upper:]' < /dev/urandom | fold -w 20 | head -n1 Write down the pin and keep in safe place.
About a year ago I was musing with a few colleagues about the next big development in Software Engineering. My expectation was the “single unified monolith” that most team would be migrating back to. The voices saying that cloud offerings, and Kubernetes in particular, are much too complex where getting louder and louder.
At the time I did not write about it, as I had no idea, what form this monolith of serenity would take, or I would come from.
From a discussion with a few colleagues, I was assured of the impression, that while, allmost everybody in software developments knows three things: a) the process (what process?) in most organisations is broken and b) everybody has heard that other, larger better organisations use modern methods (”Oh, that, yes I read about <fortune 500 company> is doin’ it.”) and nobody is using it themselfs, for various reasons. Myself included.
There are a number of small things that you can introduce piece by piece into your development process and see if they work.
For the last few years Microsoft Server Software and Linux Products have not realy been competing very much. Both sides where too busy gobbling up the large chunks of market real-estate that where left dormant by makers of large scale servers, who where unable to offer efficient and easy to use entry-level servers. Also the market for those entry class servers was growing and this class of servers was continuosly moving onto higher and higher ground as the performance parameters of off-the-shelf PCs grew in leaps and bounds.
In a recent Op-Ed piece John Seigenthaler Sr., lets us know about his understandable dissattisfaction with the contents of the Wikipedia entry about his person. He rants about the inability of legal discourse against libelous writers and prophecies a dark future where everybody can say what he wants to say.
I completely agree with Mr. Seigenthaler that libelous content anywhere should answer to legal discourse. His further actions document that, while difficult in the maze of participants (the service provider wikipedia, the ISP of the original writer, BellSouth, and the yet unkown original author of the ‘pedia entry), he can file a suit agains John Doe and persue due course of the law to take the perpetrator to task.
