devops

For over a decade, two similar concepts — DevOps and Site Reliability Engineering (SRE) — have been coexisting in the world of software development. At first glance, they may look like competitors…
— À lire sur altexsoft.medium.com/devops-vs-site-reliability-engineering-concepts-practices-and-roles-8d38b3a92f34

DevOps et Site Reliability Engineering (SRE) sont deux concepts similaires qui coexistent dans le monde du développement logiciel depuis plus d’une décennie. Bien qu’ils partagent des similitudes, ils ont des différences importantes dans leurs pratiques et leurs rôles.

DevOps est une approche qui vise à améliorer la communication et la collaboration entre les équipes de développement et d’exploitation. L’objectif principal de DevOps est de fournir un flux de travail continu pour livrer rapidement des applications de haute qualité. Les pratiques DevOps comprennent l’automatisation des processus, l’utilisation d’outils de suivi et de surveillance, et l’adoption de méthodologies agiles.

Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE), quant à lui, est un concept plus spécifique qui se concentre sur la fiabilité et la disponibilité des systèmes informatiques. Les équipes SRE sont responsables de la surveillance, de la gestion des incidents et de l’amélioration de la disponibilité des systèmes. Les pratiques SRE incluent l’automatisation des tâches de maintenance, la surveillance proactive des performances et la mise en place de processus de résolution rapide des problèmes.

Bien que DevOps et SRE partagent de nombreuses pratiques, leurs rôles sont différents. Les équipes DevOps se concentrent sur la livraison rapide et la qualité des applications, tandis que les équipes SRE se concentrent sur la fiabilité et la disponibilité des systèmes.

DevOps et SRE ne sont pas des méthodologies concurrentes, mais plutôt complémentaires. Les équipes DevOps peuvent travailler avec des équipes SRE pour s’assurer que les applications sont livrées rapidement et que les systèmes sont fiables et disponibles.

Quelques références utiles :

Site officiel de DevOps : https://devops.com/
Site officiel de Google SRE : https://sre.google/
Livre « Site Reliability Engineering: How Google Runs Production Systems » de Betsy Beyer, Chris Jones, Jennifer Petoff et Niall Richard Murphy : https://sre.google/books/
Article « The Differences Between DevOps and SRE » de John Arundel : https://www.thoughtworks.com/insights/blog/differences-between-devops-and-sre

En conclusion, bien que DevOps et SRE partagent des similitudes, ils ont des rôles différents dans le développement et la gestion des systèmes informatiques. Les deux concepts sont importants pour garantir la qualité et la fiabilité des applications et des systèmes.

If a startup launches with a NoOps model from the beginning, they have the potential of staying lean for longer. The saved resources can be put towards other aspects of business growth, like marketing.

This concept involve maturity and in fact a very good way to transform huge compagnies, too able to manage efficiently a transformation at scale with respect of culture.

That means also that all Ops must involve to make and operate template as the code and be able to push update the plateforme in secure way. Behind the scene It peoples build automation infrastructure and scripts to be able to update zero-day , increase monitoring and ability to be aline why the business.

Challenges of NoOps

The ideas of the NoOps movement are sound, in fact NoOps itself is not without its challenges. The idea of NoOps is based on believe that automation can handle every use case, and eliminates the need for any human intervention.

But is not true! Many organizations forget is that containerized services can still fail and need maintenance. Selft care Don’t means microservices-based don’t need an emergency response team in place during the nights to bring up any container that had crashed (which happened more often you thought).

Although you have to consider the element of failure which probably needs human intervention, NoOps is still able to remove the most need for human intervention — DevOps. In fact Ops have to maintains improve and fix path upgrade the service they provide.

What Are the Benefits of NoOps?

There are many benefits to be gained by adopting a NoOps model. The first of which is that it maximizes development time.

This process is further sped up by providing many preconfigured templates for running a specific type of application, like a apache, Node.js microservice,appache, iam module. This means no time is wasted on configuring and securing your application deployment as everything is pre-configured by the template. This kind of easy-to-use experience is also referred to as Developer Experience (DX).

This also implies that hitting milestones will be easier and quicker. With this sped-up development time, companies create opportunity to generate revenue sooner, since the software can be completed ahead of schedule.
Furthermore, NoOps allows developers and operations teams to do what they do best: develop and operate.

Both departments of a business can double down and become more productive thanks to the extra focus and time gained by this continuous development model.

So What is NoOps?

NoOps is a new development approach that involves relieving developers of needing to constantly work with operations members, speeding up deployment time, testing, and workflow.

It stems from the popular model of developers and operations teams working closely called DevOps.

DevSecOps A Complete Guide – 2019 Edition (English Edition)

Instead of working together, service providers give development teams the proper cloud infrastructure, patching, backups, and resources to work on their own. This model is highly accurate on a cloud path. Preferably to have to get 1000 équipes that should apprehend total process and ops constraints, you can do it for web hosting with an endpoint to streams, data, and so on.

The programmers no longer require feedback and approval during development, and can operate completely independently.

This also allows the operations department to focus on what they do best: project management, talent acquisition, provide a save model and update, patch, secure , optimize cost the solution used, and so on.

However, NoOps is typically most beneficial for startups that begin with this continuous development model. It is much more difficult to switch to NoOps when you have existing environments, pipelines, and deployment procedures.

As an example, NoOps seems no work well for enterprises that are stuck with a monolithic legacy application. In fact its pretty false, ops and dev already use to not speak together. This would necessary require a re-write of most of their codebase and have a to make it fit with the NoOps ideology but dev-ops is not really a good way. In this case, the no-ops have to federate and propose platform build in this model, auto resilient, including system security and infrastructure build. It operation include depot and template maintenance use as starter buy dev team. That means Ops strink but Ops are main actors and update the platform and rebuilt all applications based on last master depot each-time its needs.

Additionally, if a company adopts NoOps later in the business cycle, they may have to shrink the size of their operations team and upskill. In other way in fact, today most of the legacy is not really uptodate and is a vulnerability and this approach seems a way to reduce the gap. Stop to use ours foots, use your brain.

PROJET ARTHEMIS: Thriller scientifique — Rue de Rivoli post covid-19 un matin.

My Thoughts

Continuous development model of any form in general is on the way. If you’re one of them, stop dreaming deployment and start looking forward to it by taking advantage of NoOps. Because share too many constraints and points of view are challenging, you have to simplify the schema and mutualized the solution and ingeniously on few services and fully automated it from birth to death, with observability. Stop thinking if it depends on the application, pay per use makes everybody able to get a autocorrect infrastructure, and the small need helps to make bigger for huge needs at a reasonable cost.

NoOps is an excellent choice when scaling, sharing is possible. Optimizing development and automating common procedures.

NoDev NoOps NoIT: Principles governing the ideology, methodology and praxeology of informed IT decision making.

This approach was created out of the DevOps model with the goal of further automation and faster rollouts.

It’s most suitable for companies at the beginning of the path, as it’s more challenging to reshape an entire business once a model like DevOps is already in place. So don’t miss the good way!

Copy or contact a NoOps service provider if you believe this is the direction you’d like to take your development team and start reaping the benefits today.

Somewhat we need to copy dev con use toolchain to push their codes. Ops automation builds, maintain self-care platform able to rebuild all platform each time is need base on gitops and gitcode on the master branched.

DevSecOps Complete Self-Assessment Guide (Anglais)