When the British government abolished slavery in 1833, it handsomely compensated the 47,000 slave owners for the loss of their “property” – the enslaved men, women and children they had to give up ownership of. Some of this money went toward establishing new businesses, including Greene King, which is today one of the UK’s biggest breweries and pub chains. Along with other beneficiaries from the slave trade, Greene King recently apologized for its past and pledged to invest in Black, Asian and minority ethnic communities.

This is part of what it means to decolonize your company. Decolonizing is an attempt to reverse the legacy of inequality and racism left by colonialism and redress the unequal power relations it produced and perpetuated . The process identifies these historical inequalities, then looks to disrupt their impact and develop ways of thinking that consider many diverse voices . Decolonizing is different from most equality, diversity, and inclusion work.

Decolonizing has been part of public discussions for many years . It gained notoriety in 2015 when students at the University of Cape Town demanded that a statue of colonialist Cecil Rhodes be taken down .

But it’s about more than toppling statues. For example, the Rhodes Must Fall movement focused on the wider issue of dismantling institutional racism that continues to plague much of the world’s educational, legal and business environments.

In this way, companies are facing demands to acknowledge their colonial histories and take concrete steps toward reparations. There is no legal basis for these actions, but it is important in moral, ethical and reputation terms to recognize an organization’s role in these historic legacies.

Fundamentally, decolonizing is not about absolving ourselves of imperial history. It is about recognizing and challenging the consequences of that history. Companies must understand the impact of colonialism on the global economy and the way businesses operate today . For example, where raw materials are exported from former colonies and value added goods are made in the homelands of the colonizers.

Decolonizing is not about jumping on the latest PR bandwagon or something companies should pay lip service to. Mindful of this, we propose the following steps that companies can use to start the process of decolonizing.

Research your history

An equality audit can be a starting point by using resources such as this UCL database , which reveals the identities of all the slave owners who were compensated when slavery was abolished. You can use it to explore the history of your company, its founders, partners and predecessors. As a result of this database, Greene King offered its recent apology and updated its company website to mention its historic links to the slave trade .

You can also identify the ways your company may have benefited historically from all aspects of colonialism and the communities that have suffered as a result of the company’s practices. Contrary to popular belief, the economic and developmental facts show that colonialism did not benefit the colonies .

If your company was established after the slave trade ended, consider how colonial dynamics may have influenced trade. Using the hashtag #SolidariTea , as some of Britain’s biggest tea brands have done to display support for Black Lives Matter on social media, might sound convincing. But these companies cannot meaningfully say they support Black Lives Matter before recognizing how their profits have been built on the exploitation of Black and brown labour .

Be ready to face painful truths.

Pledge to be anti-racist

A statement of acknowledgement and recognition should be informed by your equality audit. But it is not enough to avoid being racist – companies must be anti-racist.

This pledge should include concrete steps and actions the company is taking. These can be partnerships , business practices , financial commitments , diversity promotion and general cultural change.

Part of this pledge could include re-branding, as we have seen some businesses , universities and places named after slave traders do. While re-branding could be seen as a token step , for others this would be the first step to real change .

Be an ally

Leaders play an important role in decolonizing. By becoming an ally and standing with colleagues and customers against any form of exclusion, exploitation and disadvantage, companies can begin to challenge the systemic inequalities present in society.

Hiring, mentoring and promoting diverse colleagues will strengthen the diversity of thought and experience to help the business respond to the rapidly changing world.

Continually improve

The Overton window – the range of policies that are acceptable to mainstream society at any given time – is continuously shifting. In the same way that colonial practices were once seen as acceptable, actions (or inaction) that are deemed acceptable today will not necessarily be so in the future. Decolonizing must be a continuous process where companies revisit their actions and take steps to identify other potential forms of inequality that their business practices create.

Business tends to be a zero sum game, where one company’s gain is a competitor’s loss. When performance is linked to profit it is easy to give priority only to value generation rather than the morality of business actions. Instead, companies should think about ethical productivity and focus on new systems of value that are not purely financial.

Finally, taking actions as a PR exercise, or doing so because the business case is the main consideration, is simply decolonization lite . Real decolonizing is a long-term process with concrete actions that incur a short-term cost to the business, for the ultimate gain of doing the right thing.

This article is republished from The Conversation by Ricardo Twumasi , Lecturer in Organizational Psychiatry and Psychology, King’s College London ; Charlotte Horne , Postdoctoral research associate in cognitive neuroscience, King’s College London , and Jenny K Rodriguez , Senior Lecturer in Employment Studies, University of Manchester under a Creative Commons license. Read the original article .

What is ‘infrastructure as code’ and why do you need it?

As DevOps grows, it helps to know about how it works. One of the big things in DevOps is “infrastructure as code.” This means that you treat your infrastructure the exact same as you would treat your application code. So you’ll check it into version control, write tests for it, and make sure that it doesn’t diverge from what you have across multiple environments.

Handling infrastructure as code prevents problems like unexpected code changes and configuration divergence between environments like production and development. It also ensures that every deployment you do is the exact same. You don’t have to worry about those weird differences that happen with manual deploys when this is implemented correctly.

Something else to consider is that you don’t need to use different programming languages, like Python or Go. There will be some tool specific languages, but those are usually simple and have great documentation around them. The main thing you’re changing with infrastructure as code is the way that you handle your systems.

Instead of logging into a server and manually making changes, you’ll use a development approach to work on these tasks. That means you won’t have to deal with a lot of issues that only one person in the company knows about. This way, everyone has the ability to update and deploy changes to the infrastructure and the changes are preserved the same way code is when you check it into version control.

While infrastructure as code helps with many aspects of getting and keeping a reliable version of your app on production, it really adds value when you add automation to it.

Automating your infrastructure

One of the first things you want to look at is how you take your code and make it into an “artifact.” An artifact is any deployable element that is produced by your build process. For example, when you are working with an app built in React, you know that the npm build command produces a build directory in the root of your project. Everything in that directory is what gets deployed to the server.

In the case of infrastructure as code, the artifacts are things like Docker images or VM images. You have to know what artifacts you should expect from your infrastructure code because these will be versioned and tested, just like your React app would be. Some examples of infrastructure artifacts include OS packages, RPMs, and DEBs.

With your artifacts built, you need to test them just like you would with code. After the build is finished, you can run unit and integration tests. You can also do some security checks to make sure no sensitive information is leaked throughout the process.

A few tools you might write infrastructure automation with include Chef or Ansible. Both of these can be unit tested for any syntax errors or best practice violations without provisioning an entire system.

Checking for linter and formatter errors early on can save you a lot of unnecessary problems later because it keeps it consistent no matter how many developers make changes. You can also write actual tests to make sure that the right server platforms are being used in the correct environment. You can also check that your packages are being installed as you expect them to be.

You can take it to the next level and run integration tests to see if your system gets provisioned and deployed correctly. You’ll be able to check to make sure the right packages get installed and that the services you need are running on the correct ports.

Another type of testing you can add to your infrastructure code is security testing. This includes making sure you’re in compliance with industry regulations and making sure that you don’t have any extra ports open that could give attackers a way in. The way you’ll write tests will largely depend on the tools you decide to use and we’ll cover a few of those in the next section.

Testing is a huge part of automating infrastructure as code because it saves you a lot of debugging time on silent errors. You’ll be able to track down and fix anything that might cause problems when you get ready to deploy your infrastructure and use it to get your application updates to production consistently.

The tools you use will help you build the infrastructure code that you need for your pipelines. There are a number of open-source and proprietary tools available for just about any infrastructure needs you have.

Commonly used tools

Some of the tools you’ll see commonly used in infrastructure as code include:

Chef

Puppet

Terraform

Conducto

CFEngine

AWS CloudFormation

Azure Resource Manager

Cloud Deployment Manager

SaltStack

Anisble

Juju

Docker

Vagrant

R?ex

NixOS

The specific tool you decide to go with will depend on the infrastructure and application code you already have in place and the other services you need to work with. You might even find that a combination of these tools works the best for you.

The most important thing with infrastructure as code is to understand everything that goes into it. That way you can make better decisions on which tools to use and how to structure your systems.

Everything behind getting your apps to production

When you hear people talking about provisioning, it means that they are getting the server ready to run what you want to deploy to it. That means you get the OS and system services ready for use. You’ll also check for things like network connectivity and port availability to ensure everything has connections to what they need.

Deployment means that there is an automatic process that handles deploying apps and upgrading apps on a server. Another term you’ll hear a lot is “orchestration.” Orchestration helps coordinate operations across multiple systems.

So once your initial provisioning is finished, orchestration makes sure you can upgrade and a running system and that you have control over the running system.

Then there’s configuration management. It makes sure that applications and packages are maintained and upgraded as needed. This also handles change control of a system’s configuration after the initial provisioning happens. There are a few important rules in configuration management.

Systems should be converged to a desired state. Systems that run against a server and against new versions of a model to get in compliance with the existing model are called convergent.

System commands and configs should be idempotent. That means you should be able to run a configuration management procedure multiple times and end up with the same state.

Systems should be immutable. That means deployments can’t be changed after they’ve been deployed. So you would need to redeploy the whole system if a change was needed.

Systems should be self-service. Any user should be able to start a process without help from anyone else. There shouldn’t be one person with magic knowledge of how provisioning and deployments get handled.

The more complex your infrastructure becomes, the more important it is for these basic rules to be followed.

Other thoughts

If you’re wondering how you use these tools to make something useful, it highly depends on what systems you’re working with. If you’re working with simple applications, it might be worth looking into setting up AWS CloudFormation. If you’re thinking about going with microservices, Docker might be a good tool to use along with Kubernetes to orchestrate them.

If you’re working with a huge distributed environment, like a corporate network that has custom applications, you might consider using Puppet , Conducto (my company), or Chef . If you have a site with really high uptime requirements, you might use an orchestration tool like Ansible or Conducto.

These aren’t hard rules you should follow because all of these tools can be used in a number of ways. The use cases I’ve mentioned here are just some of the common ways infrastructure as code tools are used. Hopefully these use cases give you a better idea of how useful infrastructure as code can be.

2021 won’t be a cakewalk for entrepreneurs — but keep fighting

Boris is the wise ol’ CEO of TNW who writes a weekly column on everything about being an entrepreneur in tech — from managing stress to embracing awkwardness. You can get his musings straight to your inbox by signing up for his newsletter!

This is my last post in 2020, so it’s the perfect moment to declare how fucking shitty this clusterfuck of a year has been. There. I said it. And feel free to say the same. Nobody is listening, so shout it out, it really helps.

I would love to predict that 2021 is going to be all peachy and easy — but I won’t. We’re not out of the woods yet. January 1st isn’t going to be the end of all our sorrow, and it might take months for things to normalize. So yeah, hang in there, and feel free to yell curses at the sky. But then — and this is important — get back to it.

Good stuff doesn’t happen in perfect circumstances. Every crisis is an opportunity. Change comes with friction, and friction can be unpleasant. Surely we could wait until the great unpleasantness has passed, but we won’t.

We are artists — when the shit hits the fan, we live-stream that shit and make a bundle. Like Paul Verhoeven, Prince, and the cast of Friends did. Whoops, did I lose you there? That was unexpected, so let me explain and fill you with hope for the future.

Back in 1990, director Paul Verhoeven was filming Total Recall in Mexico. The filming was a disaster as the whole crew got food poisoning — except Arnold Schwarzenegger who was lucky enough to have brought in his own food and water. Now Verhoeven was in a tough bind but he didn’t want to postpone the production, since it was a huge and expensive operation.

So he found a solution: he hired an ambulance to be present on the set during filming. In between takes the paramedics would administer fluids and medication so that he could eke out and keep directing. This guy was literally vomiting and shitting himself. He had every excuse to walk away and everybody would’ve understood — but he didn’t. Circumstances be damned, he persisted.

The producers of Friends also showed grit when they needed to change their opening credits. They didn’t have the budget to realize their original plan: a rooftop party in New York. Although the series was set in New York, it was filmed in LA and all the actors and crew were based there. So in a pinch, they needed something that could pass for New York, cheaply .

They finally found a fountain that worked and decided to stage the bulk of the intro around it. So they headed out at 4am into the freezing water with no guarantee of success — at this point only the pilot had been signed.

The crew was tired, cold, and at the end of their rope. Did they walk away to their trailers, or demand a reshoot in the morning? No, they jumped back in the water and persisted. It sealed a bond that set the tone for years to come.

Back in 2016, legendary musician Prince was supposed to perform at the opening of the Super Bowl. Everything had been planned and prepared for… except for the weather.

That morning, unexpectedly, it started raining and it became clear it wouldn’t stop. That meant the stage would be slippery, storm might rage the arena, the dancers might slip and fall, and there was the risk of electrocution when the stage equipment would get soaked.

The organizers called Prince and told him the risks and how bad the rain was getting. Prince’s reply was swift, epic, and full of confidence:

“Can you make it rain harder?”

You can watch what happens in this 8-minute video , and find a new appreciation for artists who defy the odds and embrace the elements.

Next year isn’t going to be easy. This year wasn’t. We could all be excused for locking ourselves away and giving up. But we won’t. We’re going to get back to work, give it everything we got, and do our very best work. Not because the circumstances are perfect, but despite them. And with that, I wish you a happy new year.

Can’t get enough of Boris? Check out his older stories here , and sign up for TNW’s newsletters here .