DevOpsDays 2020 Geneva – Day 1

It is a pleasure to come back to Geneva after 5 years to attend my first DevOps event. I’m very excited to share with you my first day feedback, but before I would like to thank dbi services for allowing me to attend this event and continuously improving my knowledge in this growing field.

The first day started by the Welcome Speech talking about the event in general, and specially about the program and Sponsors, by the way dbi services is a Silver sponsor! I liked the energy and the motivation that prevailed the room in the Geneva School of Business Administration.

Of course, in such event we would like to attend all talks, sessions and workshops 😀 which is impossible because two streams were organized, below I will list the talks and workshops I attend today:

Now that my delivery pipeline is in place, what should I do with my organization?

Good question, Joseph Glorieux and Mathieu Brun explained different ways:

1. Do DevOps yourself by hiring or train your actual team, no dedicated DevOps guy
2. Create a dedicated DevOps Team
3. Having one Team by product, from Dev to Deployment to run one Team should do everything
4. Google experience with “Site Reliability Engineering”, forget the notion of Team doing everything! According to Ben Treynor the founder of Google’s Site Reliability Team, SRE is “what happens when a software engineer is tasked with what used to be called operations”, in fact, the status of the application tel you who should manage it…

We saw 8 cases and possibilities, but at the end as I predicted they confirmed that there is no magic solution for organization, in fact, it depends on your actual structure, Teams, applications, needs, aso. At dbi services we do our best to advise our clients at this level!

Travel to the orchestrators world

Thomas Cottier spoke about his story with containers and schedulers since few years ago. I would say this is the journey of all companies and teams that started working on orchestrators at the beginning, some of my colleagues at dbi services have already briefed me 😉 Today, its orchestrators have reached a certain maturity, but there is wide area for improvement!

The solution of merge hell in monorepo

In fact, a monorepo is a development strategy where code for many projects is stored in the same repository.
Advantages
There are a number of potential advantages to a monorepo over individual repositories:

• Ease of code reuse : Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects
• Simplified dependency management : In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase
• Atomic commits : When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell. In a monorepo this problem can be negated, since developers may change multiple projects atomically
• Large-scale code refactoring : Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor
• Collaboration across teams : In a monorepo that uses source dependencies (dependencies that are compiled from source),[6] teams can improve projects being worked on by other teams. This leads to flexible code ownership

Disadvantages

• Loss of version information : Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning
• Lack of per-project security – With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues
• More storage needed : With split repositories, you can fetch only the project you are interested in. With a monorepo, you might need to fetch all projects. Note that this depends on the versioning system. This is not an issue if you use e.g. SVN in which you can download any part of the repo

At one of our cutomers, we are actively thinking and preparing a monorepo solution.

A multi cloud Service Mesh deployment in action

The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring.
We saw Istio and how it lets you connect, secure, control, and observe services. In fact, Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code.

Tomorrow will be the second and last day, I already know which session I will attend and will keep you in touch with a quick feedback. The next step for me will be to deep inside this world which fascinates me.