Where are we going?

I think that’s the main question that a good strategy should answer. But it's hard to answer without knowing:

• Where are we now?

• How well are we positioned against other forces in our environment?

• What are the impediments that block us from achieving our target?

If we don’t answer these questions, our desired direction may just be wishful thinking. But if we do answer them, it can actually change the direction or path we follow.

Simon Wardley introduced his strategy visualization technique in 2005. If you’ve never heard of Wardley maps before, I think this video is the shortest introduction. If you have more time, I recommend reading Simon’s book (it’s free).

As he writes in the book:

… six absolute basic elements for any map which are visual representation, context specific, position of components relative to some form of anchor and movement of those components.

The first map I drew was related to my attempts to make sense of IT systems involved in payroll and invoicing. It’s not perfect, but it helped me start searching in the right direction.

The X-axis represents the evolutionary phase of components involved in the system/organization — starting on the left with “nobody has ever done this before” and ending on the right with fully industrialized experience. Imagine the electricity in 1800s and in 2000s as an example.

The Y-axis shows visibility/value of the component to the actor we are mapping for. If we use electricity analogy, a lamp is super high on the value chain for the customer, but industrial transformer (despite being an important bit of infrastructure) is way lower.

The main trick that makes a map powerful is that moving elements around will change the meaning of the map. That’s a vast difference from a simple diagram.

Platform Engineering

A topic close to my heart is platform engineering. Creating the rails that help companies deliver changes to business applications is what I do for a living.

Let’s use this as a playground for a mapping experiment.

Empty canvas

Of course, we always start with an empty canvas.

Who’s the customer?

The first thing we need to understand is who the users are that we’re building for. In this case, the beneficiaries are the developers.

We could probably add other stakeholders, but doing so might introduce too much detail into the map.

What are the most visible elements?

The next step is to determine the touchpoints.

Let’s assume that we know our developers interact with the platform through different interfaces:

• Custom-built UIs (e.g., development environment status page)

• Preconfigured products (e.g., Kubernetes cluster)

• Cloud services (e.g., AWS CloudWatch)

Let’s represent this by placing abstract platform elements on different evolutionary phases:

The red arrows on the map above indicate the platform team’s overall desire to move from custom-built elements to “as-a-service” offerings where possible. This shift alone can foster interesting discussions among team members.

Down the rabbit hole

We can denote that the platform team treats the composition of platform interfaces as a single entity by drawing a rectangle around them. It’s a minor detail, but it can help guide the discussion.

Next, we add more building blocks that support the touchpoints.

Context is always important. Let’s imagine that we’re drawing this map for internal process improvement discussions. This context will require us to plot more lower-level dependencies as well as our desired state on the map.

Note that the distances between:

• in-house Kubernetes cluster and managed Kubernetes cluster

• custom GitOps flows and Argo CD integration

These distances may represent the team’s perception of how long it might take to transform from one state to another. The red block indicates an impediment on the path to the desired state. These impediments could include:

• Internal politics

• Lack of certain skills within the team

• Important business requirements that cannot be met

• Higher cost of ownership

These obstacles can be added as notes to the map or might naturally emerge as discussion topics during the drawing session.

Is it really what customer wants?

Drawing the first version of the map may lead to a series of questions:

• Do developers really need a platform?

• Does the term “platform” too broadly define the overall direction?

• What’s higher up in the developer’s value chain?

Let’s imagine that what our developers need most are self-service environments. This is crucial because they frequently need to verify deployments in pull requests and experiment with new functional features.

In light of this, let’s set aside the first map and draw a new one with a more focused context.

Into the abyss

The current state discovery process might lead us to this map:

The most valuable piece of our platform is a custom AngularJS application running on a manually configured virtual machine, set up several years ago. The reason it hasn’t been migrated to a productized Kubernetes cluster is simply due to a lack of time and the “if it works, don’t touch it” mentality.

Another potential conclusion we might reach as we continue mapping is that the world around us has changed. There are now many simple ways to create per pull-request environments that integrate well with the Git ecosystem and chat tools. These modern tools are well-known and can fully replace custom-built components.

The beauty of mapping lies in its ability to capture the details of your internal state and the state of the world around you, enabling you to make informed decisions.

At this point, we can set aside the current map and start drawing another one.

Summary

What I’ve learned through experimentation:

• Mapping is an iterative process.

• Version one will never reveal everything.

• Draw a map. Discuss it. Discard it. Repeat.

The purpose of mapping is not the map itself — it’s the discussions that happen around it.

Let's explore some other incidents that might be relevant in this context.

xz

How much time can a hacker devote to compromising a system?

As we learned from the xz incident earlier this year (2024), the answer is quite a lot.

The xz library is widely used for compression, including in SSH traffic, which is often the primary way to access Linux machines. Imagine the potential consequences of embedding malicious code into this critical library.

Whether it was the work of a single person or a group remains unknown. However, Jia Tan spent several years building trust within the xz community by contributing useful code to the repository. They also manipulated the author by creating fake accounts to generate social pressure, pushing for certain changes. Eventually, Jia Tan was promoted to co-maintainer and managed to submit a disguised backdoor into the library.

Given that this library is used by virtually all Linux distributions, the potential for widespread compromise was enormous.

Fortunately, the backdoor was discovered before updates hit the disks.

Mitigation

What can we do?

It's currently too easy to create an account on GitHub. I believe Microsoft, along with other service providers with significant social impact, should strengthen identity verification processes. For instance, implementing a KYC (know-your-customer) process that includes credit card or identity document verification would be a good start. Software security is simply too important to leave unchecked.

Additionally, major vendors should increase their support for critical library authors through sponsorship programs. While some already do, it's not enough.

Linux OS distributors (e.g., RedHat, Canonical) need to invest more heavily in regression testing and thorough investigations. Yes, they do this already, but more can be done.

Organizations that rely on external software — which is nearly everyone — should definitely adopt data collection and anomaly detection strategies. With thousands of dependencies, you never know which might harbor a zero-day vulnerability or malicious code.

sunburst

Solarwinds is the company providing monitoring software. The hacker had access to their release system for more than a year. They managed to install malicious code into the update package that was automatically distributed to thousands of companies. The incident affected many government organizations.

Mitigation

The breach was eventually detected due to anomaly detection mechanisms and accidental observations on the client side. This underscores an important rule:

Never ignore unusual data points.

Another helpful measure is artifact validation. At a minimum, verifying the checksum of any package obtained from external channels is essential.

Additionally, most ecosystems support package signing, including:

• RPM signing

• DEB signing

• Docker image signing

• JAR signing

• NPM signing

This should be a de facto standard for any company serious about security. Package signing is a simple yet effective method to detect corrupted artifacts. This leads to another simple rule:

Only use signed packages; fail deployment if the signature mismatches.

Finally, don’t underestimate the importance of network perimeter protection — yes, the old reliable firewall.

browsealoud

Have you heard of crypto-jacking? It’s a type of cyberattack where compromised infrastructure is used to mine cryptocurrency without the user’s knowledge. This can even happen directly in your browser, whether you're on a desktop or mobile device.

A notable incident occurred in 2018 when hackers exploited release infrastructure of BrowseAloud, a popular JavaScript library designed to read website text aloud. Thousands of websites, many of them government-related, included this library as part of their functionality. The hackers injected malicious code into BrowseAloud, turning every device that loaded these websites into unwilling participants in a cryptocurrency mining operation.

What’s even more alarming is that crypto-jacking might have been just the tip of the iceberg. The attackers could have used the same method to steal personal information, including credit card details.

Mitigation

Most of the users of this library were linking directly to the latest version hosted (and hacked) on AWS. The same link was used by all — convenient, but very dangerous!

The key advice here is to avoid using the "latest" version of dependencies and always specify the exact version. Additionally, always verify the authenticity and integrity of the artifacts you use.

In fact, the HTML standard allows specifying the checksum for remote artifacts:

<script
  src="https://code.jquery.com/jquery-3.7.0.slim.min.js"
  integrity="sha256-tG5mcZUtJsZvyKAxYLVXrmjKBVLd6VpVccqz/r4ypFE="
  crossorigin="anonymous">
</script>

Log4Shell

Log4Shell is a classic zero-day vulnerability. By providing a maliciously crafted URL or HTTP header, a hacker can trick an application into making a callback to a remote server, which can then deliver and execute malicious Java bytecode on the victim’s server.

This vulnerability had a massive impact on the Java ecosystem. Although the exact numbers are unclear, it's estimated that over 80% of applications were using a vulnerable version of the log4j library at the time of discovery.

The impact was so significant in the enterprise world that even unrelated Docker images on Docker Hub had to be marked as log4shell-free:

Mitigation

In reality, most applications don't need to make external calls to the Internet. Default network policies should simply block all communication with external entities.

Log4Shell exploited JNDI and RMI, protocols that are rarely used by modern Java applications. This raises an important question for both library authors and users: Why keep outdated, unused code in your applications? Old code is a ticking time bomb.

Another critical aspect of handling such vulnerabilities is having a fast and efficient deployment process to apply fixes as soon as they become available. I've encountered companies that didn’t even have the original source code or CI/CD pipelines to redeploy their production applications with updated code.

The ability to rebuild and redeploy code at any time is crucial for security.

You’ve probably heard the saying, “If it works, don’t touch it.” This mindset is dangerous. We should continuously verify that critical elements work and remain adaptable to change.

leftPad

The leftPad incident in 2016 caused a significant disruption in the Node.js ecosystem, making most applications unbuildable for several hours.

Azer Koçulu, the author of several libraries published on npmjs.com, had his "kik" library forcibly removed by the governing organization due to a legal complaint. In protest, Azer removed all of his libraries from the repository, including leftPad — a dependency for many Node.js applications.

Mitigation

I sympathize with Azer's stance, as the legal complaint seemed insufficient to justify enforcement. I might have reacted similarly in protest.

However, this incident raised two critical issues:

• How much can we trust public repositories or the companies managing them?

• Why did the world come to depend so heavily on an 11-line code library like LeftPad?

Typically, I follow this motto:

The code you don’t need to write is the code you don’t need to test.

However, in light of this incident, insourcing a simple 11-line code block doesn’t seem unreasonable. Any developer can write it quickly, including unit tests.

Since public repositories can’t be trusted to maintain packages indefinitely, caching packages within your organization through public repository mirroring is also a prudent strategy.

Dependencies often have their own dependencies, leading deep down a rabbit hole. Ultimately, you need to understand what your applications rely on. Dependency tree analysis is a crucial aspect of an organization’s security procedures. The Software Bill of Materials (SBOM) has existed for more than a decade, and tools like Dependency-Track can help build a comprehensive overview.

Conclusion

We can't fix the world completely — vulnerabilities, compromised delivery channels, and hacks will continue to occur. However, from a business perspective, we can minimize risk by implementing:

• Stricter default network policies

• Comprehensive audit data collection, analysis, and anomaly detection

• Use of signed packages and artifact validation

• Public repository mirroring and critical evaluation of dependency sources

• Dependency on specific versions of external OSS components

• Continuous dependency tree and unused code analysis

• Fast delivery procedures and effective patch management

• Always functional CI/CD pipelines

Let’s strengthen our supply chains!

Should enterprises use multiple clouds? In fact, many of them already do.

One strategy is to use a single cloud as long as it fits the needs. Another strategy is to employ the best cloud for the job and combine clouds as a result. Of course, there are nuances to consider.

The bigger the company, the greater the chance that you are already using multiple clouds. Generic public clouds (AWS, GCP, Azure), private clouds (VMware, Nutanix), and specialized clouds (Cloudflare, Vercel) can all be combined for the benefit of your organization. Some clouds offer irreplaceable functionality that simplifies aspects of your product, while others are used for historical reasons.

Traffic

If you have just a few gigabytes of traffic a month, this would likely not have a significant impact on your cloud costs. However, if you have more than a few gigabytes per hour, a multi-cloud setup may bring you some surprises.

Traffic in and out of your load balancers, CDNs, on-prem resources, and between clouds is not free. For example, in AWS, transferring one gigabyte into or out of their networks may cost between $0.01 and $0.08 per GB. This can result in hundreds or even thousands of dollars for high-traffic configurations, such as image processing, financial transactions, and analytical data streams.

Even within the same cloud, traffic can be costly if it spans several regions or availability zones.

So, if you decide to go with multiple clouds or multi-regional setups, you definitely need a multi-cloud strategy that takes traffic costs into account.

Mono-cloud

In general, I advocate for using only one cloud platform and using it well. With the maturity of cloud platforms, vendor lock-in is not a significant problem if you are concerned about it.

If you are satisfied with the provided services, you should leverage the cloud platform to the fullest extent. This will also help you be truly cloud-native. You will be able to utilize all the extra services built into your cloud provider, such as identity management, encryption services, and network integrations. These services are usually cloud-specific but add significant value, sometimes even free of charge. For example, you pretty much always get:

• API-driven infrastructure management

• Built-in IAM (identity and access management)

• Encryption services turned on by default

• Cheap configuration and secret management

Common denominator

On the other hand, there are use cases and products where it makes sense to have the option to jump between clouds. For example:

• Video rendering services (e.g. RebusFarm GmbH)

• Decentralized network services (e.g. Mysterium Network)

• Data extract/transform/load services (e.g. Matrixify)

I do not know if the products mentioned above use multiple clouds, but doing so would give them a strategic advantage. They would be able to migrate or replicate the infrastructure across multiple providers.

Not all clouds are equal, but there is always a common denominator that you can use to jump between them to optimize costs or gain a strategic advantage.

The common denominator includes the basic Infrastructure-as-a-Service components such as servers, networking, data storage, and security. In some cases, the common denominator could be Kubernetes.

All general-purpose clouds have the required capabilities. The glue code needed to achieve portability is minimal as well.

The benefits include:

• Optimizing running costs: By using the cheapest cloud at the moment, you can take advantage of price drops.

• Ensuring uptime: Stay online regardless of a single cloud region's downtime, which can happen.

• Improving performance: Place your workloads closer to clients, as clouds have different regional availabilities.

In short…

You probably can’t escape multi-cloud reality. But you can be prepared for that.

We’ve all been there. You make a guess, and then you are held accountable for not guessing right.

Estimate is not a promise!

An estimate is your best prediction based on the current knowledge of the situation at the time the estimate is given, assuming you devote all your time and focus to the estimated task.

If you as a project manager treat estimate as a hard deadline without taking into account other aspects, then you probably don't understand the complexity of the domain (hidden requirements, unknown unknowns) or the volatility of the environment (incidents, meetings, emails) you are in.

Of course, we can expect that developers will take into account the degree of complexity and volatility when they provide the estimate. They actually do. But the thing is, it will hardly ever be precise anyway. Read on.

Precise estimates are possible, but…

Creating a landing page with predefined design guidelines and adding a lead collection form can most likely be estimated precisely, because it’s a simple and well-known domain for many professional front-end developers on the market.

Writing a script to transform data from one well-defined data source to another well-defined data storage (given that the data models match) can be estimated precisely, because there are plenty of data engineers on the market who have done that many times.

A web application with dozens of screens and custom logic can never be estimated precisely. Yes, we can plan and dissect the tasks, but it will never be precise simply because:

• requirements will add up

• scope will change

• people will join and leave

• new knowledge will be discovered on the way

• market will change

In fact, this is similar to other domains.

A car service can give you a precise estimate for changing a tire, provided they have one (or usually a pair) in stock. It’s a simple, well-defined task. They have experience, and they know how to do it.

A car service can only give you a guess when you report 'something is clunking when the steering wheel is turned left.' Most likely, this will only be a timebox that allows them to find more information, but it will hardly be enough to solve the actual problem.

A car service can hardly give you any estimate if they have 50 customers with different problems knocking on their door at the same time.

The prerequisites for a precise estimate are:

• Accumulated experience with the specific task type

• Clear and well-defined requirements

• A stable and predictable implementation environment

Those are almost never guaranteed.

Complexity is, well… complex

Quite rarely do you see the full picture. In software development and operations, there are tasks that can be estimated precisely, but in many (if not most) cases, you'll miss that one dependency, hidden requirement, or underestimate the complexity.

Humans are optimists. That might be the reason we tackle complex tasks without having all the data. We explore the task domain. Exploration leads to new knowledge and more questions.

Quite often in software, we are not just changing a tire but designing a new custom engine that meets the customer's requirements.

Of course, the software world is becoming more industrialized. We have more platforms and frameworks and define more standards. This makes us faster, but it does not eliminate the ‘unknown unknowns’ that we face daily.

Simple tasks take time

Have you ever been asked, 'Is it difficult to implement this?' The expected answer is binary: 'yes' or 'no.' But in reality, the person is actually questioning the speed of implementation. If it’s not difficult, then you can probably do it quickly, right?

The twist is that simple tasks take time. If someone tells you a task is simple, it does not mean the task can be done in five minutes. Complexity or simplicity does not directly correlate with time consumption. 'Simple' means that it's all clear and everything is known to implement it, but it can still take three days. It can also delay other 'simple' tasks in the pipeline.

Context switching is not free

Quite often, we exist in many contexts at the same time:

• project A

• annual meeting B

• strategic initiative C

• research D

• family problem E

The more contexts task implementor is in, the more likely they will lose time going between different contexts. Focus is important for faster task completion. If focus is not given, then expect estimates to grow. Naturally.

The other problem with frequent context switching is that your brain loses ability to do deep work, because it prepares you for the next switch.

This constant state of readiness for change hinders implementor’s capacity to dive deeply into any single task, leading to superficial engagement rather than thorough understanding and completion.

As a result, tasks that require intense focus suffer, impacting the quality of your work. Over time, this can erode your skills in critical thinking and problem-solving, making it harder to achieve a state of flow where productivity and creativity peak.

To improve the likelihood of meeting the estimate, you must care about the implementation environment and reduce context switching as much as possible.

Should we drop using estimates altogether?

You may have seen reports stating that '70% of software projects fail.' They went over budget and were not delivered on schedule.

The thing is, it's the same with construction projects. Have you ever heard of a bridge or public building being completed on time and within budget? Good luck finding one.

Some believe we should adopt the #NoEstimates approach, at least in software development, because we are rarely right about those estimates.

On the other hand, you can’t really give infinite money and time to implement something. It will be not sustainable for the business.

So, what should we do?

I believe we should continue estimating tasks, but we must recognize that the precision of these estimates can be significantly affected by factors beyond the professionalism or experience of the software team.

Software development is often an act of exploration. We know how much it will take to reach the mountain, but we have only a vague idea what’s on the other side.

Here are some key points to consider:

1. Estimates vs. Commitments: Never treat an estimate as a commitment unless the task is exceptionally simple or well-known.

2. Task Complexity: Always consider the complexity of the task domain. Higher complexity, lower precision.

3. Research Time: Acknowledge that research (or more accurate estimation) is a task that requires its own time allocation. The more time you spend researching, the more precise the estimate will be. But sometimes (or actually quite often) it is better to go into the exploration/implementation mode and get results faster.

4. Task Outcome: Precise estimate is never the target. Value that customer gets is the target. Always search for the shortest path to that value.

5. Time Boxing: Professional software development team can deliver value daily/weekly/monthly. Focus on what’s achievable within the time box.

6. Continuous Plan Refinement: Plans are not set in stone. They change. Every time box/iteration will bring adjustments.

7. Task Breakdown: Always dissect tasks into smaller, more manageable units.

8. Implementation Environment: Minimize context switching. Reduce time spent on wasteful activities. Aggressively remove unnecessary tasks from your backlog.

9. Building Trust: Foster a strong trust relationship between the customer and the software folks.

10. Transparency: Be transparent about progress and any impediments that arise.

Good luck with your projects!

The Extreme A will be about many things, but they all revolve around building and supporting software systems: #DevOps, #Automation Tooling, #Software Delivery, #Team Structures, #Strategy and more.

I’m a big fan of visualizations (sometimes even more than writing), so you can look forward to a picture or two in every post.

For shorter shots of Extreme A come and hang out on Substack Notes — it’s a bit like Twitter, but nice.

Happy reading! Content is coming soon!

Subscribe now

What is needed to setup a domain for a modern organization? Just buying a domain from a registrar is not enough.

You have to:

• Decide whether you will use your registrar for DNS record management or you will use a different DNS provider (e.g. Cloudflare or Microsoft).

• Select a hosting provider where your website code will be deployed. Or deploy it to your own servers.

• Of course, the website has to be developed as well but that’s out-of-scope for this post.

• Add an A or CNAME DNS record to point to the location of your website.

• Ensure that your hosting provider gives you an SSL certificate for your domain. Or generate/buy your own from a different provider and upload that to your hosting provider.

• Ensure that there is a redirect (on the hosting provider level) or CNAME record (on the DNS provider level) to automatically go from www.mydomain.com to just mydomain.com. The www prefix was cool in 1999, but in 2023 even browsers hide it by default.

• Ensure that you redirect from port 80 to 433. Nobody wants to visit a website that does not show a lock icon in 2023.

• Does your DNS provider support DNSSEC? Domain hijacking is not a myth. You better enable DNSSEC. A couple of DNS records need to be added.

• The domain registrar stores information about you that is publicly visible. Things like your email address or physical address may appear in the records of public WHOIS databases that registrars are mandated to support. If it contains just official company data, then it’s probably OK. But quite often those records reflect private data of company owners. That’s not OK. On the other hand, many registrars support WHOIS information protection services. For extra fee, of course.

• Then you have to select a mailing provider.

• Add MX records to point to your mailing provider.

• To fight spammers who pretend to send e-mails on your behalf, you have to add an SPF record that contains a list of allowed IP addresses from which you expect to send e-mails to your clients. Even though this record format maybe a bit outdated, it is still widely supported.

• Additional protection can be reached by adding DKIM record with the public key of your mailing provider to sign messages that you send.

• To get insights into SPF/DKIM alignment from the perspective of your e-mail receivers, you may also add a DMARC record that contains policy settings and mailbox that will get reports from other mail servers.

• Those reports are quite technical, so, you may want to sign up for a DMARC service that will analyze those reports for you. For an additional fee.

• Add a BIMI record that will contain the link to your brand logo. That maybe used by mail clients and search engines to show your brand identity.

• For even better brand exposure, you may need to buy a Verified Mark Certificate (VMC) and add another entry in your DNS provider. That’s quite expensive.

• Setup MTA-STS and TLS-RPT records to ensure that messages between your SMTP servers are encrypted.

• Planning to run ads? You may have to add several TXT records to verify domain ownership at different providers.

Did I forget anything?

For example, cloud-native does not mean it runs in the cloud. It means, it surely can. But it rather means that the application or automation component has certain properties that, in fact, make it very convenient to run anywhere: on your laptop, inside a Raspberry Pi, inside an on-prem data center, or in any region of AWS, GCP, Azure, and other clouds.

On the contrary, you can run a non-cloud-native application inside the cloud as well. Take a big Java monolith running only on WebLogic, and deploy it to a big fat EC2 instance running as part of an EKS cluster in AWS. It will work. It does not make the app cloud-native, though.

The hub of cloud-native technologies - the Cloud Native Computing Foundation (CNCF) - defines it like that:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.

Scalable, dynamic, modern. Those are the keywords. Cloud is just an example of the modern runtime environment, where we can deploy our cloud-native technology or application.

Did you know that F16 fighter jets also run on a cloud-native technology - Kubernetes? That is probably as close to the clouds as it gets.

Some other define cloud-native as leveraging the cloud computing model:

Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model.

According to the above definition, cloud-native is something that is built specifically for the cloud. Honestly, that would be a more correct and self-explanatory definition. But that’s not how people use the word.

All-in-all, it’s a nice marketing term that seems to be a synonym of cool and lightweight. Maybe we should blame the marketing department for the confusion.

Another term - Serverless - does not mean there are no servers. It rather means that servers are hidden enough by the platform abstraction layer. But they are there. For sure. Serverless is more about effective integration with existing managed services and cloud offerings. Serviceful, if you will. It’s reliable, scalable, event-driven.

Serverless tech is cloud-native, by the way.

Serverless is also a different billing model compared to the traditional server approach. Pay-as-you-go instead of pay-for-uptime. So, serverless is about billing and integrations, not about the absence of servers.

Software industry outsiders will definitely not get all the nuances 🙂. Insiders are confused as well. Sometimes.

P.S. On a side note, cloud computing actually happens on the ground. Sometimes underground. Sometimes underwater.

Now we have DevOps engineers, DevOps teams, and DevOps departments. New silos? Maybe not.

It makes sense! If done right. DevOps people are building rails for development work to run smoothly through the organization.

Today, DevOps has basically turned mostly into Platform Engineering with many good practices formed around it and lots of useful tools reaching their maturity. Meaning that we can outsource many things and get running and reliable infrastructure/pipelines within days.

OTOH, I see situations when the industrialization of DevOps stands in the way of development.

Platforms become so complex that they require more effort to maintain than business applications. Processes are built around blocking interactions between Devs and DevOps.

Is a new wall being built? I hope not.

I’ve started my professional career in 1999. A lot of rather revolutionary events have happened since. They have shaped modern software delivery, infrastructure management, automation, and me.

The below events are important to me as a professional. What are yours?

💡 1999 - Extreme Programming (or XP for short) practices are defined.

💡 2001 - Agile manifesto is written.

💡 2003 - Lean Software Development book is released.

💡 2006 - AWS is born. First global infrastructure as a service (IaaS) provider. It was called “Lego for IT world”.

💡 2007 - Heroku is born. One of the first global platforms as a service (PaaS) provider.

💡 2007 - Infrastructure-As-Code is becoming a mainstream concept.

💡 2008 - DevOps term is born and the community starts active discussions around it.

💡 2010 - DevOps = C.A.M.S. (culture, automation, measurement, sharing)

💡 2011 - Continuous Delivery practices are defined by Jez Humble and Dave Farley.

💡 2011 - Folks from Heroku define the 12-factor application manifesto (a.k.a cloud-native).

💡 2012 - Serverless is mentioned for the first time.

💡 2013 - Docker is born. That changed the way we look at application deployment forever.

💡 2014 - Kubernetes is born. The future winner of the orchestrator wars.

💡 2014 - AWS releases Lambda = function-as-a-service (FaaS). Serverless approaches growing in popularity.

💡 2017 - GitOps is defined by folks from WeaveWorks.

Imagine you find yourself in the middle of a city you have never been to before. No phone, no money. What would be the first question you ask a stranger coming your way?

I guess: “What is this city?” or “What is this country?”

How stupid do you think it will sound to that person? Very stupid!

But you need the answer in order to start your journey home or any other desired destination.

Whenever you start learning, ask questions you need an answer to keep you going. It does not matter what other people might think.