staging-devopsy.kinsta.cloud

Tag: thoughts

  • DevOps: What It is and How to Cook It

    DevOps: What It is and How to Cook It

    What is DevOps?

    DevOps is a funny concept.I have spent the last few months trying to find an accurate explanation of what it is, reading books, articles and participating in discussions which led me to the following personal definition: DevOps is a set of processes which aims to enhance the Application Lifecycle Management (ALM) of an Agile project by creating tighter links between the different actors (Developers, Operations and testers) through the use of automation and communication. Wow!

    Why DevOps?

    The traditional development cycle of an Agile project usually leads to two to four major releases a year which means the delivery of a lot of new functionalities, tons of bugs fixes and therefore a lot of testing pre and post production. Such releases can prevent the good visibility of specific problems in the application itself; create a huge stress on the people involved as it is not conceivable to miss a deadline with two releases a year, and create an ever-extending list of requirements for the next release.

    While many important projects succeed in this approach, many major companies such as Facebook, Amazon or Flickr have chosen to perform shorter cycles of over ten deployments to production a day. That process enables them to have a very specific scope per release and with the help of automation almost everywhere, especially in testing, creates higher quality deliveries.

    How to DevOps?

    One important thing to remember here is that you cannot call Merlin and ask him to send you a “DevOps person” to solve all your problems, including your personal ones.

    In order to achieve a successful transition from a two-releases-a-year cycle to a ten-releases-a-day one, it’s going to take time, a lot and skill, a lot. The team in charge of the changes will have to study the way you work, analyze the current process, identify potential problems and then make a list of recommendations

    Those recommendations usually include breaking the different walls between people. One big goal of DevOps is to make people realize that whatever their role, their objective is common with the rest of the project: to deliver quality and to do so efficiently. Imagine for one second that a bug is found in pre-production (it happens). Usually the sysadmin will perform an analysis within its domain and if he cannot find the cause or identifies it as a “not my fault”, will forward the bug to the development team who as usual will answer “it worked in dev., must be environment related”. The pointing fingers game will take some hours maybe days before someone finally jumps in and finds the problem.

    Now imagine the same bug handled by people on a project where DevOps is used correctly. When the bug is identified by testers, developers and operations are contacted together and retrace all the steps. Is it due to an error in the specifications? Can we reproduce it in other environments? What changes in the code triggered that bug and so on and so on. By having people working together instead of one after another, you create ownership of the product and a strong team feeling. If everyone is concerned when a problem arises and if everyone understands the application from the conception to its application, problem solving becomes a breeze and an actual good way to create natural collaboration between people of different groups.

    The other main changes that come with DevOps are related to automation. Maybe easier to implement than mentality changes, setting up automated releases, testing, deployments requires expertise and a lot of testing on the way but can lead to great time sparing.

    DevOps in Real Life.

    One my favorite thing in life is food. Eating it, making, talking about it… Let’s use food as a simple example of how to use DevOps.

    Imagine yourself in a starred restaurant kitchen; there is the executive chef, a sous-chef, a saucier and a vegetable chef.

    The chef has envisioned a dish and asked his new staff to do their parts based on what he explained to them. Ideally this would go well but: the sauce is too acidic for the vegetables and the plating is terrible with the shapes and colors making the dish look sad. Everyone blames each other and the utensils for not being adapted.

    Add a zest of DevOps to the recipe and try again.

    Now the vegetable and saucier chefs work together and make sure that what they produce respects the wishes of the chef while working perfectly with the protein produced by the sous. It doesn’t happen instantly but they all try the overall dish together and after many iterations, manage to produce an experience that is visually astonishing on a plate and which flavors combine divinely in a way that is neither too heavy nor too light. To be able to cook and plate correctly, they had to buy more adapted utensils that everyone in the staff could use if needed.

    One month goes by and the head chef asks them once again to repeat the operation on a new dish.

    This time the whole staff knows how to work together and while everyone is working on his own specialty, they all work together from the beginning, sharing their experience with the utensils and understand which way to go, tasting their creation as they progress, leading to another perfect dish done in a much shorter time.

    DevOps is not magic.

    Many things can go wrong in a project and DevOps might be one possible solution to solve some specific problems but it is important to remember that implementing new processes, changing mentalities and using new tools can take a very long time and be really expensive.

    You have another definition? You don’t agree With me? Feel like adding something? The comments are here for that, please let me know what you think, sharing is caring!

  • COBOL: Completely Obsolete But Omnipresent Language

    COBOL: Completely Obsolete But Omnipresent Language

    The programming language COBOL is a nuisance, something everyone wants to get rid of; however, I’m about to advise you to learn it. It might be a gold mine.

    The IT world is a fast paced one where obsolescence is the rule and where things evolve so fast that any person who wants to understand it has to continuously learn and train. Languages, methodologies and technologies keep on changing, evolving to make programming easier, safer more robust and above all, faster. As to every rule, there is one exception.

    In 1959, convinced that the English language would be more suitable for programming than machine code or the assembly language, Grace Hopper creates the first ever human-readable programming language that would survive for over fifty years: COBOL

    COBOL, 55 years old and still in its youth, not ever thinking about retirement, has become a nuisance, something everyone wants to get rid of but no one has the courage to try.

    Are we ready to replace COBOL?

    Nowadays, 80% of financial transactions are made through COBOL programs and most of those programs have been written decades ago and have proven to be reliable, effective and efficient. To top it all most companies which are still using it have invested a lot of money in those systems and if it is not broken, why fix it?

    So why would one want to change them? Well, it’s not Java. COBOL was created in an era where IT didn’t have the meaning it has today. A program was mainly designed to replace simple repetitive tasks such as retrieving data from a database, performing a couple of operations and generating a report or updating some other data. Today’s programs have to present a front-end to thousands of users, go through different layers of security, logic and quick data retrieving before accessing the back-end to ultimately alter data and send some information back to the user. Alternatively, a program can be a tool to design objects and buildings, communicate with your friends, frag your opponents, enhance your reality, you name it… The whole philosophy behind the conception of programs has changed so much in the last two decades that having such an outdated technology that almost no one knows anymore represents a potential danger. Only few people learn COBOL these days and even though those systems are not supposed to evolve much, there is always maintenance to be performed. But are we ready to replace it just yet?

    Fast, robust and future-proof language

    COBOL has been on the brink of death for years but its presence overall hasn’t changed. Not only are the cost to migrate from one technology to another huge but the choice of the replacing technology itself is a million dollars question. What better than COBOL to perform typical COBOL operations? While not designed to be an Object Oriented Language such as Java or C#, COBOL has slowly adopted some of their aspects, extending itself and its functionalities to a point where almost everything is possible. Everything with the exception maybe of creating user friendly or good looking Human-Machine Interface. In that matter, nothing has changed much since Hopper’s time. Many of us still remember the frustration of spending hours to get a simple screen with a couple modifiable fields and those who still use them must be dreaming every day to replace F5 and F6 by simple buttons…

    But that was never the point; the point was to have a fast, robust and future-proof language.

    COBOLs main contenders

    The discussion is still opened as to which language could replace COBOL but here are some pros and cons to the main contenders:

    –       Java is easy to learn, well spread and has a huge community of developers already but is rather slow compared to other languages despite the existence of some specialized compilers and massive improvements in the last few versions. It is also arguably still in its youth and the yearly evolutions and changes to the language don’t play in its favor. Not to mention the recent security issues.

    –       C++ is fast, flexible and robust but it takes time to learn and understand and has what is maybe its biggest flow, potential memory leaks. Something COBOL and Java programmers have, almost, never heard of. By conception, it offers a lot of freedom to developers but that also implies few ready-to-use components and thus it’s less cost-worthy.

    Let’s say that one day we manage to find a clear winner, another major problem will suddenly emerge. COBOL was made to perform all kind of operations in one block but we have learned throughout the years that modularity is the key to success. So if we replace COBOL itself by another language, we will also need to have databases and SQL, a front end and HTML, most likely a Business Process Management Software to externalize workflows… Basically, replacing COBOL programs means creating whole new ones.

    The ultimate piece of advice

    While it is possible to replace this aging language, this comes at such an extremely high cost that we can anticipate its presence in at least the next twenty years which brings us to the ultimate piece of advice of this paper: if you have the opportunity to learn it and enough motivation to write white on black interfaces, go for it. The pool of competent COBOL programmers is getting smaller by the day and the demand doesn’t change, meaning that this personal investment might reveal itself a gold mine.