# Stuck in the Past (Monolithic Pipeline) --- ### Part - 1 <!-- Put the link to this slide here so people can follow --> Slide: https://hackmd.io/@-tzmTxyyTcaycndedBYuhA/rkP6cEis_ --- Private Weekly Architecture & Knowledge Sharing Session. 20 June 20201 --- > Oftentimes, especially when you work for a larger company, you have no control over the situation you’re in. I’ve worked for companies that have had feature requests pile up, which prevented any discussions of refactoring an application. > --- ## Monolithic Application --- Traditional Monolith Application.  --- Sometimes the configuration isn’t even separate, it’s baked into the source code. In this scenario the user interface (UI) lives with, and is usually packaged with, the application code. Applications like this are **usually built on MVC frameworks** that bring front-end rendering and server-side code all in one neat package. These frameworks are great for rapid application development, but usually result in poor decisions in code structure, separation of concerns, and flow. --- Traditional Monolith Application with another layer.  --- Now imagine if you have **two or three of these applications**. The deployment process becomes so much more complicated. - From a developer point of view, you never want to touch the code, especially in business-critical areas. - As a system team (DevOps or Sys Admins), you dread deployments, as they are error prone and take a lot of time. --- ## One Pipeline per Application --- A lot of monolithic applications are still deployed manually, even in 2018! The deployment process involved the developers manually building and packaging the code, and placing it on a shared drive or FTP folder on the network. A Sys Admin would then copy the compiled code and paste it on the production servers. --- How can organizations deploy applications like this? Well, these practices exist for many of the same reasons as monoliths. - We’ve always done it this way. - The deployment can’t be automated. - The business won’t give us time to build it out. - We don’t have DevOps expertise. --- > ***Most simply reflect fear of doing something new or moving away from a method that works.*** > --- > ***If your monolith is a commercial off-the-shelf product, you may not be able to automate the deployment.*** --- > ***Good Practice:*** Developers can maintain feature or development branches that will eventually get merged into “master.” In this scenario “master” is the source of truth, and the only branch that ever gets deployed. ---  --- ***Problems:*** Sometime Having a single pipeline per application can introduce some bad behavior. Larger code bases that have a dedicated pipeline, bad practices begin to emerge. --- ***Bad Practice:*** large that it becomes difficult to easily merge it back into “master.” Now we have our pipeline deploying off a feature branch. --- > If you have multiple teams working on several features, which branch is now the source of truth? --- > ***Bad Practice:*** request to turn off certain stages in the pipeline. ---  --- ## Agile & Monolithic development time problem --- Extremely long lead time to deployment. With a typical monolithic application, the time it takes to deploy from the moment work begins on a new feature can be weeks or months. ---  --- >The longer the cycle time to develop and deploy a feature, the more out of sync your feature branch becomes with a “master” branch. --- This Long cycle time **introduces a lot of risk** from many different angles: --- - Developers - Merge to master problem. This is one of the main reasons that long-living feature branches exist. Your “master” branch is pristine and you’re hesitant to mess with it. However, the long cycle time means your feature branch must also live that long. If multiple features are being developed concurrently, by the time you need to merge back into “master” it becomes a real problem. --- - Testers - don't see new feature for quite some time. In this scenario, testers don’t see the new features for quite some time. In some cases they don’t see compete functionality until the code is ready to go to production. This introduces even more risk if a bug is found. --- - DevOps - the subtle nuances that come with that process are forgotten One of the selling points of pipelines is an automated process that is repeatable; you know what you’re getting every time you request a new build. If you’re only deploying once a month, that process is not performed enough to become routine. If you’re doing manual deployments, this means the subtle nuances that come with that process are forgotten. Each deployment then becomes as if it’s the first time you’re doing it. --- ## Are you also stuck in the past? ### If yes, I want to hear your story. --- # Part - 1 (END) ---