How to become a DevOps engineer

max-duzij-qAjJk-un3BI-unsplash

How to become a DevOps engineer

It’s a big industry, software.

There’s a lot of money to be made, and a lot of fun and satisfaction to be had. With skills in DevOps, you’ll always be in demand – as a freelancer, or as an employee. But DevOps isn’t for everyone, and it’s certainly not an easy ride.

Let’s look at what it takes to practise DevOps, and how to become a DevOps engineer.

First – what do DevOps engineers do?

The definition of “DevOps engineer” is pretty broad.

That’s mostly because DevOps isn’t a “thing” that you engineer – it’s a practise, or a culture, or a mindset. It’s a way of working; lean and agile, where small teams with overlapping skills fulfil many roles in parallel.

That doesn’t stop the role being advertised, or the title being used when technically, it doesn’t exist!

Semantics aside, DevOps engineers are highly sought-after.

They’ll usually have the following responsibilities and more:

  • Building and automating infrastructure
  • Writing CI/CD Pipelines
  • Designing DevOps strategies
  • Managing version control (usually Git-based)
  • Working on multiple platforms across different programming languages
  • Creating and configuring container orchestrators
  • Working closely with developers to write well-designed microservices architectures
  • Providing support to internal and external stakeholders
  • Ensuring that all workloads and infrastructure are secure

This is really just a general list, and the actual responsibilities will vary from company to company.

To boil it down to the simplest explanation, DevOps engineers build the processes that turn code into a product.

What will always be true is the need for a solid understanding of the DevOps culture, and a core set of technical skills.

What skills do you need?

DevOps engineers are excellent problem solvers – but they need to be collaborative, and work well with others. DevOps engineers manage teams of developers, so they need to have a strong knowledge of the SDLC (software development life cycle): the six–stage process which guides software development projects. Above all, they need to be excellent communicators and have soft skills to match their hard skills.

As a bare necessity, you need the six technical skills common to every DevOps role. These will be your gateway into technical DevOps and better jobs:

  • Using the Linux operating system
  • Basic programming skills
  • Bash
  • Git
  • Fundamental knowledge of networking
  • Fundamental knowledge of Cloud platforms

If you already have these skills, you can apply for entry-level DevOps roles – for more advanced technical DevOps roles, you’ll need to understand the CI/CD pipeline: the production line of software companies.

How to get DevOps technical skills

As with most things, the best way to learn is to do it for real. This means daily, focused work – making mistakes, learning from them, and logging successes.

Doing this off your own back will teach you to be proactive, a soft skill that’s essential to DevOps. But you could also learn on the job, at the right organisation.

There are many courses you can take to hone your technical skills – Learning the CI/CD Pipeline in tools like GitLab, or learning to use Docker (the most popular runtime environment for containers).

The hard skills can all be taught.

The thing you really need for DevOps is a set of soft skills; and some people think you can’t learn those.

We beg to differ.

Soft skills – can they be learned?

Understanding the DevOps culture is key to your success. DevOps culture is pinned on transparency and open communication – and this is why DevOps isn’t for everyone. Some people just work best solo, or are set in their ways. And that’s fine, too! You do you.

The fact is that soft skills are harder to learn. Some say they are unlearnable, but we think that’s bunk. If you really, really want to make it in DevOps, you’ll do it. And humans learn best by doing and practising.

To hone your soft skills for DevOps, focus on developing the following – and train yourself to build these skills.

Prioritise communication and collaboration

Learn how to write clearly, effectively, and mindfully. Learn how to speak to others as your equals, and expect mutual respect.

If working with others is something you struggle with – don’t be ashamed! It’s a challenge for lots of people, most of us are just better at hiding it. Instead of shying away, try to apply collaboration skills in low-stakes environments, like gaming. Ease yourself out of your comfort zone.

Be proactive

This is the number one soft skill for anyone who wants to become a DevOps engineer.

The good news? If you’ve set yourself the goal of becoming a DevOps engineer, and started learning how all by yourself, then you are by definition a proactive person. You simply took the initiative to do what needed to be done, and here you are. Even just by reading this article, you’ve made a step to better yourself and become who you want to be.

The trick now is to carry on – and never stop.

If you can keep going, you’ll certainly figure out how to become a DevOps engineer. Try not to forget us when you do…

ClearHub – the home of DevOps professionals

ClearHub specialises in placing and sourcing freelance DevOps engineers – vetted, skills-checked and ready to work. Join us as a contractor, or hire your ideal candidate. To get started, call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

Software startups: how to avoid growing pains

ga-XncszFVfqhE-unsplash

Software startups: how to avoid growing pains

We live in a time where information is everywhere.

Information about everything. How to make perfect pasta. When to plant potatoes. Which exercises build muscle the fastest. Even how to start a company, and how to run it.

This is all truly great stuff that blurs the lines between education and entertainment. You can learn how to do something, from an experienced practitioner, and usually for free.

But the reality of software startups is almost always shielded from you.

The hard work and the failures of tech startups are rarely shouted from the rooftops, and when they are, it all seems so inevitable and obvious. We only tend to see the ones that make it, and assume that they’re the best. The ones that fail? They didn’t have “the formula”, or the “mindset”. Or the product.

Survivorship bias leads us to believe that you must do things a certain way in order to succeed. You’ve got to have all that trendy startup stuff – open-plan offices, a dog, flexible working, unlimited time off, beer fridges, ping pong, and above all, total freedom.

This is your company culture, right? Isn’t this how all the best software companies motivate their teams to produce their best work, and ship fast?

Not really. Because nobody tells you how bad it can get when this culture of freedom collapses in on itself, trapping those within it in a cycle of burnout.

Freedom versus burnout

A well-intended culture of freedom, styled after the “best in the business”, can turn sour. Usually, it’s slow and insidious. Like boiling a frog slowly, employees don’t immediately leap out when it all gets too hot to handle.

Take flexible working hours, as an example. It’s such a great concept on paper – and in bigger organisations, it works well.

But employees in startups more regularly feel a sense of duty – to always “be on”; emails, Slacks, WhatsApp groups – notifications are constantly pinging. And not just in work hours. At bedtime, on weekends, during annual leave… It’s never-ending, and always urgent, somehow.

Flexible working practices can work brilliantly at established software firms, where there’s plenty of headroom. At a startup, with only a handful of developers and coders, it’s a one-way, fast-track ticket to crunch and burnout. Employees can suffer in silence during phases of growth, stretched to their limits, working all hours.

But you’ve got unlimited paid time off, so that’ll balance it out… right?

Well, only if there’s enough staff to cover the employees taking unlimited PTO. And if they’re even willing to take it.

Have you heard of “option paralysis”?

When humans are presented with unlimited choice, we can become paralysed by the options, never choosing anything for fear of making the wrong choice.

Unlimited time off can have the same effect on our brains.

Imagine sitting down for a meal at a restaurant, and being presented with an enormous menu. Tens of pages of dishes, and each one sounds completely delicious. How long will it take you to order?

Now imagine you’re at a food truck that sells tacos. Just tacos. There are 3 toppings. How long are you going to take to order?

The point of all of this is: there is such a thing as too much freedom in software startups. But the very things that make startups attractive to talented devs and coders – like agility and autonomy – need a level of freedom.

So how do you balance it?

How to ship and version software quickly

The answer is to maintain the sense of freedom, but contain all activity within a structure. There must be processes, and clearly defined boundaries. That structure will look different at every software startup; because all of them have learned in very different (often painful) ways, that one size does not fit all.

It’s the ugly stuff that nobody talks about. The pain of growth. The lessons learned.

You need to be able to work as a team, at all times – even if that means taking a long break to be at your best. Above all, you need to define your processes, and your workflows. 

Reduce burden, improve productivity, and give freedom to innovate within frameworks and allotted time.

Shipping software fast means using time where it counts, and front-loading releases for the best outcomes.

 

1.  To ship software fast, implement code reviews. More often than not, the biggest problems come from code that wasn’t reviewed before launch.

2. Measure everything you possibly can, both in-house and user metrics. What’s the development lifecycle? Where are the bottlenecks? How are users interacting with the software – and have there been any dramatic changes in usage since the last version was shipped? Keep watching those metrics – because they’ll guide improvements in speed and quality.

3. Roll out slower. This sounds really counterintuitive – if you want to ship software fast, why would you push for a slow rollout? Well – by introducing changes to a smaller group of users first, you can track their experience, perform A/B testing, and limit the number of incident reports – allowing your team to work faster overall.

Scaling with contractors

Another, and an increasingly popular answer to the growth problems startups face, is to expand your team on a per-project basis.

Hiring experienced, ready-to-go contractors allows startups to scale up and down with requirement – and the freelancers you hire in can impart valuable knowledge onto your core team.

ClearHub helps software startups in the most important phases of growth, to hire DevOps contractors and consultants, and seasoned practitioners, who can jump on a task and just get it done.

We find the people who push teams forward and pick up the slack during heavy workloads.

Read more – How to manage a mix of staff and contractors

We’ve got decades of experience in enabling fledgling software teams to become industry leaders. And we do that by placing the right talent at the right company,

Let’s do it for you. To get started, call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

What will software development look like in 2030?

sebastian-svenson-LpbyDENbQQg-unsplash

What will software development look like in 2030?

Cast your mind back, if you will, to 2010.

Do you remember what the biggest leaps in consumer and business technology were back then?

It was the year that Instagram launched. The first iPad was introduced. Cloud computing went mainstream, with Microsoft Azure going up against AWS.

Major disruptors had yet to even enter the market. Uber? Not a thing until 2011. Same goes for Snapchat and Minecraft.

The most powerful games consoles in 2010 were the PS3 and XBox 360.

In the years since, technology has snowballed in its importance and its power. Tesla has made electric cars attainable, consumer drones have transformed content creation, and social media has evolved into a world-changing force.

But technology, and the software that enables it, has only just begun to explode.

What will the landscape look like in 2030?

Computing trends: so much power, still untapped 

Computing hardware is still mainly driven by Apple, Intel, AMD and Nvidia; and while they all depend on the same subcontractors, supply chains, and outsourced industrial processes – they are all independently racing towards new architectures.

Intel is famed for resting on its laurels, after establishing itself as the de facto chipmaker of the 1990s and 2000s. After that period, it was all AMD – but there was a push/pull relationship between the two silicon giants for the best part of the 2010s.

AMD eventually leapfrogged Intel for innovation and raw processing power in 2019, with the Zen architecture and its Threadripper series, effectively doubling the performance that Intel could offer, at any level.

And in 2020, Apple moved from Intel to processors designed in-house, with the M1 architecture; an entire system on a chip (SoC). This combines CPU, graphics and RAM into a single piece of hardware – one chip instead of many. While not the most powerful chips in the world, they remain, watt for watt, the most efficient desktop class processors in the world.

And it’s scalable. Shortly after M1 came M1 Pro, M1 Max and M1 Ultra; all use the same die, chopped, left whole or stuck together, for whatever level of power is required.

This started a chain-reaction of chipmakers developing their own SoCs to compete – and the race to become the most powerful, most efficient is now in full swing.

This means that consumers will have more power in their devices than ever before. Businesses will have faster machines, with less power consumption. Creators and the people behind the content we love will be able to make more compelling, beautiful, amazing experiences for us.

But all that power needs software to be able to utilise it effectively.

Otherwise, it’s a little like trying to drive an F1 car to the shops.

How will software change to use this new power?

Apple’s choice to transition from the established x86 architecture for desktops and into the ARM architecture (more traditionally seen on mobile devices) has caused some upset. Even two years after M1, and a full three since Apple announced the move, there are many flagship pieces of software that do not run natively on the architecture.

And this is just how it goes for new tech; devs and programmers have a lot of work to do in order to adapt. Making them from scratch is comparatively much easier – ARM has been around since 1990. But translating entire codebases to ARM is not as simple as it seems.

But it looks like this is where computing is going – and over the next five years, we expect developers and programmers to be focused on transitioning, because the software itself will have opportunities to become more powerful as a result of the improved power density that ARM offers.

This new power might bring new capabilities; like truly lifelike VR. Games could become more like simulations, and the much-touted metaverse could actually be realised in a way we can’t currently imagine.

Enhancing software to use the full potential of future hardware could make processes that currently take minutes or hours – like rendering large CAD or video files – instantaneous. 

Even for those of us who simply use tech to consume the content that we love, more power means more to be entertained by.

And the next revolutionary leap in tech won’t be hardware; it’ll be software.

Self-driving cars are physically possible with today’s hardware. We just don’t have the software to match. By 2030, we could have made that leap. We could have also given up our healthcare to technology over humans, our legal system, our educational institutions… 

And if that all sounds a little bit scary, well – it is. But we’re not here to discuss the pitfalls of a world run by AI this time around.

Except that is, if AI is making the software.

Will we even need devs by 2030?

Self-building software and AI-powered tools are going to explode.

Take DeepCoder, introduced in 2017. It’s a machine learning system that writes its own code, in much the same way humans do:

It takes existing snippets of code from other sources (in repos or from Stack Overflow and the like), and stitches them together. After it combines them, it tries to fill in the gaps – effectively determining which pieces of code are useful, and getting the desired outcome from chopping and changing.

Right now, it’s not very good. Humans are still better. But it’s learning – and ML, like humans, gets better as it does more work.

Unlike humans, ML never gets tired, and can continue improving at a geometric rate.

We will absolutely need developers and programmers in 2030. But by 2050? Machines could be doing all the work themselves.

Until then, we predict that the 2030s in software development will probably look like this:

  • A full adoption of Cloud Computing and centralised infrastructure
  • AI assisted software development, overseen by humans
  • Low code and no code building environments will enable more people to make software
  • New programming languages will emerge to utilise the latest tech
  • Artificial Intelligence will become far more advanced

Looking for a freelance DevOps expert?

ClearHub specialises in finding the best freelance DevOps experts in the world; vetted, skills-checked and ready to go. To get started, call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

Software versioning: how to launch with FEWER complaints

sad face
sad face

Software versioning: how to launch with FEWER complaints

If you’ve worked in software development long enough, you’ll have lived through at least one “ropey” version release.

It could be version 2, or version 12 – but generally, the more complex a system gets over time, and the more features are added, the more likely you are to encounter an issue with a version launch.

And the larger a user base grows (on multiple devices, operating systems, browsers – you name it), the more opportunities there are for user error, bugs and incidents after a launch.

Sometimes, it’s inevitable; no matter how hard and diligently we work, we’re not perfect. But it’s frankly amazing how many issues can be avoided with a new version release – with simple, effective communication to your users.

Oh, and forget emailing your release notes, “HOT NEW FEATURES!” lists or press releases. Because half of the time, those emails go straight to spam. The rest either get ignored or misinterpreted.

Thankfully, there are better ways to communicate with your user base and ensure a smooth transition between versions – with fewer complaints and support tickets.

After release, users complain of reduced functionality – even if it’s all still there

A major release can be gruelling, even before changes are committed and rolled out. But once users are in the application – things can get messy.

Sometimes, functions and features are moved to make room for other, newer or higher-priority features. If you haven’t effectively communicated this to your users, expect a bunch of support tickets asking why they can’t do “that thing” anymore.

Remember – not everyone has the time to sift through their emails and read version notes. Many inboxes will filter out mailer bots, especially in high-pace, high-stakes organisations. So, while an automated email is an easy and simple solution for you, the people who actually matter aren’t getting the information they need, or it’s being presented in a woefully ineffective format.

Absolutely – you need to have version release notes. But does everyone need to read them? Think about a few ways to improve the release experience for users:

  • Add a “new features” pop-up to the login or launch screen. Keep it quick and simple, to prevent frustration
  • Get your PR and marketing teams to help develop key messages, or:
    • Write like a tabloid – give your users HEADLINE information of new features, then link to the full version release notes
    • Try a short “What’s new in version X” video explainer
  • Communicate over multiple channels, not just email. Have a solid message across all channels, and link to release notes

To stay ahead of the game, check forums for common issues with other releases (not necessarily your own) and try to preemptively mitigate any issues you encounter in them.

Uh oh. This actually IS an incident!

Incidents happen. And they’re serious. Speed of response is your greatest asset during a major incident, so make sure you’re ready.

Connect your CI/CD pipeline to Jira Service Management (or other ITSM platforms) to give your team a speed advantage when identifying issues that have just been released to the live environment. 

Good housekeeping is the key here; build categories using multiple attributes, so that high-priority items get noticed first. Set event thresholds on the number of linked incidents, and then define automated escalation paths.

Jira Service Management Service Centre and Confluence can work together to speed this up and communicate clearly during an incident. Use tags and keywords to raise content before a query is submitted.

When a high-level incident occurs, you will likely be following your major-incident process. Some of this will happen within your workflow, with automation and integration between your ITSM and documentation or collaborative workspaces.

Some of this will fall outside of ITSM; managing resources and relationships.

Senior leadership will be asking questions. Customers will be pushing back.

All the while, your dev team will be working hard, trying to resolve the incident. It can be tempting to bombard them with status requests when you’re getting the same. But be mindful of the impact this will have on their focus, their efficacy, and their wellbeing.

And be mindful of your own.

Major incidents are rare, but when they happen, you want to know you’re prepared to limit the fallout.

Is your Jira and Confluence set up to handle a major incident after a version release?

Hire an Atlassian expert to supercharge your workflows

ClearHub specialises in finding the best Atlassian contractors in the world; vetted, skills-checked and ready to prepare your DevOps and ITSM platforms to handle anything.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

5 DevOps tips – all don’ts!

JUST DONT
JUST DONT

5 DevOps tips – all don’ts!

This blog is a safe space – so let’s just say it.

DevOps is hard work and boring.

There. We said it.

To most people in tech and software, DevOps is tedium and busywork that gets in the way of the “real” work – making software.

This is why it’s often left by the wayside, or done improperly. 

So, what if we told you that if you got it right, your job would be better, more fun, your business more profitable – all that kind of pie in the sky fantasy stuff?

The fact is – DevOps works. That’s why there are entire industries around it. But it requires the right mindset, the right skill set and the right people to really nail DevOps effectively.

If you can avoid the most common pitfalls, you’ll stay ahead of the competition. And in tech, you’re rarely at the top if you’re not one of the best.

Done right, DevOps delivers a fast, autonomous culture in a large organisation – where continuous product flow is the norm. But without guidance, teams will only ever pay lip service to DevOps, and never realise the potential of it. It’ll end up a box-ticking exercise, and eventually fall by the wayside again.

Don’t let that happen; in fact, don’t do a lot of things… 

Here’s a top 5 list of everything not to do when you adopt the DevOps culture.

1. Don’t skimp on skills

You can’t just say “hey, we’re DevOps focused now”, and leave it at that. You’ve got to invest in it for the desired outcomes.

You’ll need people with specific skills to get DevOps running effectively. You can train and upskill members of your team, or make new hires – or seek out contractors and DevOps consultants to help a small team transition, without committing to a new full-time employee.

Keep on top of training, and make sure everyone’s on board. Like we said – it can be boring to those doing the work day in, day out – so streamline it and make it simple where it counts.

DevOps can only succeed when everyone in the team is familiar and comfortable with the tools and processes. Give tailored access to tools and functions to individual members, to keep it simple – it’s more likely that they’ll integrate it into their day this way.

2. Don’t miss the metrics

With sophisticated analytics built into modern DevOps tools, getting data isn’t the problem; using it effectively is.

One of the biggest keys to success in DevOps is keeping track of progress. And to do this, you need the right metrics. By making the relevant measurements and then adjusting processes and tools, you’ll get the best results.

And if you don’t? You’re fumbling around in the dark. With no data to base your decisions on, you’ll have no insight into what’s working. Everyone wants to see different results and at different stages, so make sure the team and leadership all agree on goals before delving into DevOps.

3. Don’t choose tech over people

Automation, smart features, and advanced technology are no substitute for people. DevOps needs buy-in from the top down, champions in the company and collaboration throughout –  tech can’t provide that mindset. It can only facilitate it.

The success of DevOps depends on the bringing together of teams. Nothing happens without effective communication, collaboration, and cooperation. Culture makes companies successful, and the same goes for DevOps. That’s got to come from leadership and filter through everything you do.

And no – after work socials, a coffee machine and a ping pong table are not a company culture. But feeling safe to speak about problems and to communicate with key people across teams is a sign of a good one.

Put your people first. Run through new tech and processes with them first. Value them over the tech in play first. What’s good for your team is good for business – and for your DevOps strategies.

4. Don’t assume automation will fix everything

Automation is important – but working with legacy systems across multiple departments and siloed teams, it can be hard to know where to start. It’s easier in startups and small, agile teams, where things move quickly and teams are encouraged to fail fast. In older, larger, slower-moving firms, not so much. Automation takes time, and it may not become full or standardised over your tenure at the company.

A bad automated process is exactly the same as a bad manual process – it’s just bad.

Instead of automating, fix the manual process first: figure out where thighs fall off track, and how to improve what you already have in place. Then, seek to automate tasks within the process.

Test it on a live project that’s fairly low-stakes. You’ll need experience of it in practice, but don’t go all-in until you’ve established a framework for automation.

5. Don’t forget to rinse and repeat. Always repeat…

DevOps, completed it mate. Said nobody, ever.

DevOps is all about continuous, incremental improvement. It’s a marathon, not a sprint – or actually, it’s more like the development of an athlete. It takes dedication, drive, and a desire to be the best version of yourself. Talent alone won’t get the results; you need to constantly be working towards the goal, assessing performance accurately at each key phase, and making changes to improve weaknesses.

This goes for your product, your team, your process – everything. Good DevOps never stops. It’s not a destination, it’s a journey.

And if you need support, we’re along for the ride.

One more… Don’t forget to hire elite-level DevOps consultants

ClearHub specialises in finding the best DevOps consultants in the world; vetted, skills-checked and ready to get results.

Want to know more? Get in touch with the ClearHub team today – call +44 (0) 2381 157811 or send your message to info@clearhub.tech.

 

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email