Posts | Louis Holleville

Distorted agility

Thu, 11 Jan 2024 14:55:00 +0000

The Agile methodology, through its different frameworks (XP, scrum, kanban, etc.), holds many promises.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The great strength of agility lies in the incremental delivery of functionality whose customer feedback will allow adjustment as development progresses. By moving from a waterfall-type tunnel effect to continuous delivery, the client co-constructs the final solution. Excellent way, therefore, to ensure satisfaction of a product that we are partially creditable of its completion.

The Waterfall method

Before agility, the Waterfall method was the most widespread one in project management. Simple to understand, it consists of emphasising the preparatory phase so that the implementation which follows only has to follow a path so marked that the execution and the result deviate only slightly from the plan.

Waterfall workflow

An example of a waterfall managed project could be the construction of a car as follows: we take the driver’s need, we design all the plans according to the driver’s dream car then we send the car into production to the factory. Once the car is produced, it is tested to ensure that it works properly and delivered to the customer. Finally, we will take care of maintaining the car throughout its lifespan with the customer.

The Waterfall method also presents some constraints:

the preparation phase being substantial, the arrival of changes along the way is impactful.
the risk of the non-alignment of needs. As the requirement is only collected at the start of the project, its development is tunnel-based, costly and even more so if the result achieved miss the requirements.

With our car example, here’s what could be failing:

plans do not reflect a technical reality achievable in the factory.

test cycles show technical or design failures that require backpedaling to previous stages.

the customer wanted a city car and not an SUV.

The agile alternative

Agility, unlike the waterfall method, integrates customer needs throughout the development of the project. The initial phase of need analysis is shorter. The deliverables are also shipped more quickly, barely functional and gain consistency as iterations progress. The interest lies in taking feedback from customers and their needs in order to adjust as you go. This makes possible to optimize the entire production by providing exactly what is expected each time, no more no less.

The customer wants a car. The need is taken and synthesized, the teams begin to think about the design. The first drafts are presented to the client who specifies his expectations. The carcass is sent for assembly and the customer validates the structure. Now, the engine is added but upon inspection, the customer wants a more modest engine: the engine is changed. Ultimately, the customer obtains a completely assembled and functional car.

Limits

However, this promise is subject to the reality of the market and business. If deliveries have become periodic, it is also linked to the financing of the projects that has been staggered, subject to proof of satisfaction.

Many companies distribute periodic budgets to their projects/departments. Their amount is based on previous, future or expected results. This also allows these budgets to be adjusted and not to have to tie up large sums of money (sometimes) unnecessarily.

And from then on, this condition of satisfaction is transformed into a quest for approval. And this is where the shift can occur. We move away from the rational, and from the proposal to complete the project in the right order, to focus on the “wow”. If the stakeholder sees things that he likes, he validates. It doesn’t matter if it makes no sense in the production of the project, or worse, it doesn’t matter if it slows down/disrupts its smooth progress. And as the stakeholder is often involved, directly or indirectly, in the project budget, it is vital that he propagates a positive opinion.

Positions of those who distribute the budgets are ejectable, one another. Credibility and longevity therefore depend on betting on the good horses.

And agility is thus twisted. The door is wide open for the project manager to approach the PO with a new idea that will impress the stakeholders. Would the very vision of the project be compromised? No matter, now that the project manager knows that agility “welcomes” change. And then difficult for the PO to fight back with rational arguments because we must remember a second reality, the project manager very often has hierarchical ascendancy over it.

Who has never heard a PO declaring a “NEW RULE!” ?

Not all environments operate like this and cases where governance plays it alone are not the norm. But the more room there is for politics in business, the more agility becomes a weapon in this house of cards.

Discover GitOps!

Tue, 28 Mar 2023 22:50:00 +0000

GitOps is an approach to operational management that uses Git as the source of truth for infrastructure and the applications deployed on it. This method is based on the idea of versioning configuration files and infrastructure definitions in a Git repository, which serves as the single source of truth for all system components.

Thus, with GitOps, all changes to infrastructure or applications are made through changes to the Git repository, either manually or through automated processes. For example, when a developer makes a code change and pushes it to the Git repository, the GitOps deployment tool detects that change, builds the application, and automatically deploys it to the appropriate infrastructure. The state of the infrastructure is updated, taking this latest addition into account.

The advantages of GitOps are multiple and converge, in the DevOps movement, to rationalize processes while making them more accessible, more open:

Single source of truth: the GitOps being based on the versioning of the resources, it consists of the only reference of the state of the infrastructure. Not only are we reducing the human factor in knowing this infrastructure, but we are also simplifying its management and ensuring its consistency!
Continuous integration: gitops goes perfectly with automation. We can thus draw the full power of the DevOps approach by extending the continuous deployment of applications with the continuous deployment of infrastructure. We increase the SLA, we perform precise, reliable and repeatable MEPs!
Traceability: the code being versioned, we also exploit all the capacities to trace the changes, to control who can publish; a big plus for safety. Finally, like authentic developers, we provide the ability to revert changes in the code and therefore the infrastructure!
Collaboration: one of the big challenges of the infrastructure is to get out of this fatality that the infrastructure is inaccessible to ordinary mortals. Now, the infrastructure is described on YAML (or other) in an (almost) readable way for humans and above all, centralized. It may be necessary to equip yourself with an infra->English dictionary at first, but this change alone is a giant step!

In more technical terms, there are a few tools that allow you to orchestrate turnkey GitOps in a Kubernetes application context. The two relevant tools in my opinion are:

FluxCD: an open-source tool that deploys in server mode directly on the target cluster and allows you to define custom workflows. This tool is intended to be handled in CLI but is very light.
ArgoCD: also open-source, the tool is very complete and a little more substantial to deploy (Helm is your friend). It is GUI oriented and allows a fine management of users allowing them to also have their hands on the management of the environment. I personally have a preference for the latter, I’ll let you figure out why.

There are also other tools, or other methods of managing GitOps. Some involve a little rock&roll management of gitlabCI, GitHub Action and co. Others, like JenkinsX (Jenkins in the name) don’t necessarily appeal to me right now.

In conclusion, GitOps is a powerful tool for configuration management and continuous application deployment that offers a single source of truth, continuous automation, full visibility and traceability, efficient collaboration, and enhanced security. GitOps is a growing trend and for good reason: simplicity, speeding up deployments while reducing human error.

Quick note about multicloud

Sat, 10 Dec 2022 14:55:00 +0000

A few days ago, I was able to attend a conference dealing with multi-cloud¹. The very content of the presentation ultimately turned out to be just a wobbly pros/cons table about multi-cloud. In the end, the most interesting part was the question and answer session. As I was very skeptical about the speaker’s answers or even about his somewhat too enthusiastic posture for multi-cloud, I wanted to offer some feedback on this theme and give my position.

Multi-cloud is not something desirable today.

And I will start by recalling, as mentioned by the speaker, the benefits of multi-cloud:

the ability to bring competition into play when negociating/choosing services. That is all. And even this unique advantage can be discussed. Because in a context where just finding an infrastructure engineer is a long run, do we really want to waste this precious bandwidth on a multi-cloud?

The only reason that can lead to an acceptable multi-cloud situation would be legacy, such as acquisition and merger. Otherwise, don’t go there voluntarily, because having to work on the lowest common denominator of different clouds would take us 10 years backward. The future of the cloud is in the managed, is in the vendor-locking.

It’s quite shocking to say, but let’s understand that the resources of ICTs are limited. So limited that investing the equivalent of a salary in a tool that would save man-months is the kind of leverage that ultimately allows you to effectively manage your budget. Let’s not be hesitant to engage deeply with a cloud-provider, whichever it is, because all the power of their solution really happens when fully used. And it’s not achievable here for multi-cloud. Very few companies are able to retail a painless lift&shift, quite the contrary. It saddens me even more that firms such as the presenter’s advise on this type of time-consuming infrastructure, and it is in their very interest.

The only thing multi-cloud can do is reinvent the wheel at your expense.

We are talking here about the use of 2 or more cloud providers for infrastructure and operational management. No hybrid fleet here. ↩︎

About the complexity of working with AWS resources

Thu, 08 Sep 2022 17:55:00 +0000

The Cloud is a marvelous tool, the flexibility it gives us is of incomparable added value to the infrastructures of not so long ago. No more need to be predictive, anticipating needs, no more need for unfindable and overpriced CISCO experts. Why bother with so much knowledge and layers of knowledge when others can do it much better, in a shared and affordable way? Recently, I had the opportunity to work on the network aspects of our infrastructure at WeMaintain and to rediscover the huge range of tools offered by AWS to solve the least of our needs. But the experience was not as ergonomic as I might have expected. Should she have?

The dynamic of cloud players in recent years has been to make more and more services accessible, at a lower cost. Thus, a lot of infrastructure was born there and a lot of existing infrastructure migrated there. At the same time, access to its services has been simplified, making the appeal stronger and the user experience more engaging, in my opinion. In this dynamic, in 2022, I set out to want to create a [virtual private network (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc. html) in AmazonWebService (AWS) in order to test the possibility of creating an isolated zone of the Internet, access to which is only possible from a bastion and the purpose of which is to operate only services internal to our IS. In an ideal world, this VPC was only connected to the internet for the purposes of updating its components.

Initial needs schema

The reality of the execution was slightly different and that’s where we get to the heart of the matter. Even though access to these services has been simplified, their use has remained more or less the same. CICD, subnet, gateway but if all the keywords are not there, all the concepts remain the same. There is now even an additional layer: that of the cloud provider. By adding their interfacing to these network concepts, they have developed their own modules that meet their own rules and recommendations. Thus, a network expert must now also be a cloud network expert. The complexity rises when from Azure to AWS the names, the rules also change. And here we are with a whole new profession. Not that it’s embarrassing, because it covers much more needs with less competence, but that one would have expected that it does not exist at all.

Indeed, I was greatly surprised when I myself had to implement network architectures based on basic needs. Creating a VPC isolated from the internet doesn’t seem so specific to me. Creating a VPC that cannot be accessed from the outside doesn’t seem like it to me either. And yet, it’s up to me to do the research, to document myself to accomplish this according to the standard of the cloud provider in question.

Wouldn’t we be at the peak of cloud and no-infrastructure? Because if a dynamic is clear, it is that of making the cloud so accessible that the only profession associated with it is “expert click-click AWS/Azure/etc”, if this were still to be a profession and not just a training.

Still, my job as an engineer allowed me to get out of it in an afternoon. Can we go further?

The final form of my project’s infrastructure ultimately looks like this and I imagine it to be the standard, according to my research.

Final VPC schema

It could even have been even more perfect if I hadn’t realized that players like GitHub¹ didn’t yet manage IPv6 and if I hadn’t had to integrate an IPv4 layer despite it, I would have had a egress IPv6 only, which is damn sexy.

In the near future ?

Shame ↩︎

ArgoCD in production at WeMaintain !

Sun, 28 Aug 2022 16:00:00 +0000

Why not manage your IS like a business product? Consumers, customers, suppliers, MVPs, stakeholders, planning; the more I think about it, the more common notions I see.

So all we were missing would be the link between theory and practice?

Not so much now: Infrastructure as Code, Network as Code, DevOps and now #gitops, all these concepts take shape through solutions such as Terraform, Istio, Ansible, Argo and many others. Put end to end, the evolution of an IS is now completely possible through the code, like a project as a whole, and can itself be subject to the automation of its deployment (So InfraOps?: p). The infrastructure becomes reactive. Cloud technologies now allow us great flexibility, we are no longer anticipating a few years but reacting to a few minutes. The infrastructure becomes apparent, malleable and can now closely follow business needs. Its operating processes are automatable and rationalizable, maximizing repeatability and reducing the human factor, the dream. CI over GitOps, canary and blue-green now even allow an automated delivery workflow, from the smallest integration to production. And most importantly, other people now have the opportunity to consult this “new” code, to contribute to it, to question it and to bring a fresh, naive, vital vision to it.

Having laid the first GitOps brick at WeMaintain last week, I am already delighted to see the growing confidence in our processes and I am impatient to be able to go even further. And, I must say, it’s a real pleasure to work in an environment that aims so far and gives itself the means to do so.