Feedback on the Devops Survey

Well that survey is out, and I have to say, it is interesting. There will always be a continual change in the definition of “Devops” to an organisation. I will not go through the whole document, but I shall summarise what I think about the points in the executive summary;

This is the survey document link

“Devops” has become a term synonymous to tech at all levels. Everyone speaks the lingo, and buzzwords; to garner attention and also the brightest technicians in the market. Given so, doing “Devops” is like being in the English Premier League; are you the next company out there to buy the best engineers the market can offer and entice them about doing “Devops”?

There are still obstacles of course. From the document, it says “lack of skills”, “legacy infrastructure” and “adjusting corporate culture”. I can probably break it down from my own experience dealing with all above.

I remember when I was switching roles from one space to another, my job title was “devops engineer”. As a “devops engineer”, I am meant to know about infrastructure, code, and distributed systems. Basically a “Jack of all trades”. Sometimes the expectation of being a “devops engineer” is that you are a sponge who can understand everything. In my honest opinion, this expectation will not change.

“Legacy Infrastructure”? Really?! What is legacy? To me it was what is built yesterday, supported through traditional operations and hard to change. I think “legacy” just means “yesterday and I don’t want to touch it anymore, please give me something brand new, and shiny to build”. The honest truth, you will never get a shiny new project and most of the times, you will inherit bad infrastructure, legacy infrastructure to build on, and manage. Use the principals of “Devops” there instead. No complaining.

Adjusting Corporate culture is a tough one. Ive been in many organisations and through many changes. For some companies, changing a culture meant buying, oops hiring “devops engineers”, and everything to do with “devops”. From human capital to toolsets; and sell the idea to the bosses. In my opinion, “devops” is a movement, and its about the small steps in huge organisations to show that it works. It can be a small effort that moves on to bigger things. You have to win the hearts and minds of your engineers so they can pass on small wins to their managers, then continually up the chain. Buying tools and engineers do not change a company, influence does. There is always a fear of job loss, when certain roles become irrelevant, but thats life. We need to evolve. I was a classic operations engineer once, I moved from there to being a SRE/Devops engineer. It was evolution through hard work.

Communication and collaboration is critical in “Devops”. Tools and Personnel make a small difference but communication drives this. Communication and collaboration is what drove the “Devops” movement. NOT a list of tools and team buyouts. How are you doing your “devops”?

Fault Tolerance and High Availability – New World

Fault tolerance and High Availability are very subjective when it comes to environments. In many cloud environments, High availability is often celebrated and sold upon to customers. For example, managed services by cloud providers often say, there is no need for managing the infrastructure as its highly available and if one piece of the infrastructure goes down, there is a redundant piece of infrastructure.

Can fault tolerance and high availability be taken for granted then?

As we move to infrastructure being software defined, a lot of implementation and management is done via code. Infrastructure is built via code, and a lot of work is done on the software side more than the big chunky server code we were used to a decade ago.

How do we redefine high availability and fault tolerance?

In the case, from my experience, we look at distributed and decoupled systems; and also a serverless environment where possible. In a highly complex environment, a distributed and decoupled environment can help reduce fault tolerance because of an easy decoupling when a section of the environment can be pulled out of a system and an alternative be used.

For example, lets say, if we had a CD system using a SaaS product to deploy our code into the infrastructure, and it broke down; we can cut-over to a simple serverless CD to deploy into our infrastructure. Of course, you may ask, why not just use the serverless CD as our primary system? In certain spaces, we might have licenses we might have inherited to make use of and we cant just use a quickhack .

Did you just see what I did there 🙂 ? People have always associated high availability and fault tolerance to cost more. In my opinion, it is how we do it. If we had a primary service running on servers, can we utilise containers as a secondary system or even serverless? This gives a great impetus for infrastructure/platform teams to build redundant services for less. Of course there is initial cost and learning curve that engineering teams need to pick up; but in the long run, cost drops as we can run a hot-hot environment, being a servers-container environment, or servers-serverless environment.

I am back.

Following up from lesson 2, it has been around 2 years now since my last post. 2 years of doing heaps of Site Reliability Engineering work with multitudes of customers in the managed services space.

Things have been great, I have been doing heaps of work around Lambdas and AWS, where I do not need to worry about patching, maintenance work and mundane routines, as it has all been coded as “functions-as-a-service”. This is a continuous exercise, as the goal is to be 100% automated. As my life time goal my favourite quote would be, “Being a SRE, means thats all the automation done, only gives us the room to put our two legs up a desk and watch Netflix. The only time we get called is when the moon turns blue” 🙂

As this is my first post after a long two years of absence, it would be great to summarise what I have been up to lately.

I have written and developed solutions for clients using the AWS Simple Service Manager, which manages AMI building, Patching solutions and compliance. This integrates various parts on the AWS ecosystem which does not cost anything and works smoothly with no hiccups. Pretty cool for a SRE like myself dealing with multiple clients.

I also have gone through strides in getting my AWS certifications up to date and picking up some programming skills along the way to fully utilise the Lambda functionality.

I have also moved on from API Talent to Deloitte as part of an acquisition exercise which means that it would be an awesome time to actually be part of the pioneering cohort of SRE techs for Deloitte New Zealand.

In my next post, I will be continuing my season of episodes on my journey from being an ops tech to a SRE tech;

Yay to Serverless.

Recently I had the privilege to attend the ServerlessDays Auckland 2018 event(https://serverless.org.nz/). The drive to run this conference comes from the events that occur around the world called JeffConf, now called ServerlessDays(https://serverlessdays.io/).

Serverless have been a buzzword for a couple of years now; starting off with the Serverless Framework(https://serverless.com/) to AWS coming up with AWS Lambda(https://aws.amazon.com/lambda/). Serverless is defined in simple words as a technology framework where developers can write code without having the need to build/operate servers. In this case, all developers need to do is write code, and vendors will manage the infrastructure behind the scenes.

The speaker list was impressive; from Randall Hunt, Matt Brown to Adam Larter; there was a varied representation from big vendors, to internal teams. What made the talk interesting is the capacity of using serverless to run enterprise environments at low cost.

Operations to Development Journey Episode 2

In episode 1, I have touched about my direction of being an operations guy moving towards being a SRE. That is a long journey with many beautiful scenic routes as well as pitfalls. I did explain briefly about the tools i am using in AWS to pave this journey as well as the little things like indulging myself with Cloudformation and FaaS (Function as a Service).

For episode 2, we continue…

We did notice, the first step out from operations is being a developer

AWS has pride itself in being a developer-centric platform, from its RESTful API to the induction of FaaS environments like Lambda. Lambda uses Java, Python or NodeJS. Blurry! 🙂  So how does an operations guy make the first step in making in roads to being a developer?

Well, I have to say, a developers mind, is amazing; from the ability of writing many types of languages to developing software. These guys are like creators. Me, an operations guy, I am like a doctor, i get problems all the time, i fix them, no problems, happy day. But this is diminishing because systems are getting very immune to failures, with the introduction of H.A, Self Healing applications and lesser complicated machinery which works on small functions of code to run a software (micro-service architecture?) So where does the operations guy fit in this realm?  How do we do it?

Lesson 1: Change your mindset. 
Switch your mindset! Now from being a doctor, you would have to apply that body of knowledge to become a creator instead. Think about it….. to solve a problem you would have to know the architecture well enough to isolate the problem and fix it… now whats changed, is the direction. You now create.

Lesson 2: Learn a Language.
Learn a language! ffs theres million of languages. some do Java, some do python, some do Go, some do NodeJS, hell, its like a freaking universe of languages. Gotta admit, Developers are demigods. Now, where do i fit in? Perhaps learn YAML or JSON? Mind you, my focus is AWS. Something to build some resources on AWS.  Smalls wins grow to become bigger wins. Learning Java, or Python, or any other language might be a challenge considering the “genetic” make up of an operations guy who has no patience in writing stuff, but building quick fixes and moving on. Now comes the next lesson.

Lesson 3: Patience.
Patience, my young paduwan…
Being in Ops, you/I/anyone is probably the fastest person around to jump into it and fix the problem. Well, development is not like that. You will need to break the patience barrier and be ready for fail, fail, fail and more fail. BUT again, fail fast and rise again. And again, we are not fixing fires, and looking for quick fixes… we are now looking for more permanent, and sustainable solutions which use code and is reusable next time. That takes time. Like Diamonds.

Personally, i am at Lesson 1, i am learning to be a Creator, and i am slowly transitioning into learning a language, which is Lesson 2. In the next episode, i shall introduce a little problem i am trying to fix which would test my patience, which is Lesson 3. Till next time… happy developing, mr./ms. ops 🙂

Operations to Development Journey Episode 1

I am an operations guy making my way to understand the intricate nature of development and of course the whole craze about Devops and Site Reliability Engineering. Before one can jump into Devops, one has to start off with this steps in mind from being operations only.
Operations —> Developer —> Devops —> SRE
SRE would be considered as supercharged Devops, as performance becomes the quintessential criteria in running an environment already practising Devops.
Where do I start? I am an support/operations technician. I would probably deep dive into Lambda, and Cloudformation. It would probably be a mine-field at first, as everything in the world of AWS is very developer-centric.  This is part 1 of my journey.
Lambda has been the toast of AWS for the past few months and the whole buzz about serverless came about starting with Lambda being a classical FaaS. What is FaaS? It is function as a service, which means we can write up functions without the need to worry about the technicalities of managing a server and running server-side tweaks to get your code deployed in a jiffy.
As the Serverless buzz is taking place at the moment, I am two steps behind, trying to convert some of the manual tasks to Lambda driven activity. The problem with that is, when an environment fails inevitably, we will not be able to access the service within the region. Hence the deployment of Lambda encapsulated in Cloudformation. To top it up with an icing, ive added cloudwatch events as well on Cloudformation.
To counter this, I have been working on converting some of my little manual Lambda scripts to Cloudformation templates. Believe me, it’s not an easy task for an operations guy to put on a developer’s cap, and convert functional scripts to proper coded templates. Having that in place, with a standard, having to deploy lambda functions in another region without having to spend time doing it again, would be done in an instant.  

My current project, were to convert all activity to be done a monthly event to a proper CFN template with inbuilt Lambda functions and Cloudwatch events. Once that’s complete, it would definitely be my first step into the developer’s world, as an operations-only technician.

My rant of day: secure payments online. fail 101

Lately i have been paying my bills online. I have great belief and trust for the state of security that modern giants have especially when online payments are done. But, lately i have become wary about the tardiness of some companies to take web security for granted.

The last payment i did, was one i did for family and this is a top-up for the mobile. The general assumption, is that it is all secure to run payments online. Wait, no. Make sure, you “watch” your surroundings on a website.

When there is a payment page generally, you would not want to have anything on that page. This only increases the attack surface for a hacker. You would want a separate page, that only has HTTPS transaction, and does what is necessary.

However, this spectacular vendor, failed security 101. It is definitely dense to have a “search bar” and other non-secure Artefacts on a secure payments page. Even Chrome said its a site worthy of snooping or an attack. Hell no, i am not going to put PII on a page and make payments like that.

What saddens me however, is how ignorant or less-savvy tech of this vendor is about the secure payments page. I wonder how long would it take till someone actually makes use of this terrible coding mishap.

I wont disclose the vendor here, but if you do your top ups online, please be aware of your surroundings on a website before making a payment.

Update your openssl version on Mac OS X using Brew

Just thought of putting something across for future use. How do you update your openssl version on mac.

By default the openssl version is 0.9.8 and we know that ain’t the current standard.

So first step.go to brew.sh and find this particular link. Click and paste on your terminal
ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”

Next, do a update check.
brew install wget

In particular, you can use this script; brew install openssl

To check if the version was updated, you then use openssl version -a

I am not sure about this line, but you can try if this line works to enforce the openssl upgrade.
brew link –force openssl

If its not updated, then you will probably have to manually enforce it, then what you do is scroll up the page and check where the latest openssl is installed. For me it was in the /usr/local/bin/openssl
Next thing to do is to create a local backup, you can use the mv /usr/local/bin/openssl /usr/local/bin/openssl_OLD

Once that is done, you can now create a symlink using the ln -s command. The new openssl is probably located in /usr/local/Cellar/opensslx. figures brew and cellar (smile)

You then, place this command on your cli.
ln -s /usr/local/Cellar/openssl/1.0.2e_1/bin/openssl /usr/local/bin/openssl

In some cases the openssl might be in the /usr/bin/openssl instead. so be careful.

Next thing you do, you turn off the terminal and get back on it, type openssl version -a   It should be there now.

Setting up sys-admin capability for Amazon Web Services on Mac OS el-capitan

Hello.

If one is starting to do AWS system administration work like i am, then the first steps you have to take to make sure AWS-CLI is installed. It can be quite tricky to install awscli in the latest Macintosh OS, the El-Capitan.

First you will need to make sure pip is installed. Pip is inherent to the latest python installation, so there is no need to follow the long pathway of running through an installation. Next, make sure you install the AWSCLI this way.

sudo pip install awscli –upgrade –ignore-installed six

The reason for this is that mac-os already has a six folder installed and it will fail the installation process and you will be wondering where you failed. So you should save that trouble!

Next, please configure your credentials by typing “aws configure”. Have your secret key and secret access key ready for this. configure it easily. Another way is by typing

export aws_secret_key=…; export aws_…. ;export aws_region=..

If this is a little tough for you; typing aws configure would do! This is step 1 done. Step 2 would be posted in my next column.