This content originally appeared on DEV Community đ©âđ»đšâđ» and was authored by costica
I think Continuous Delivery is the magic sauce that allows web to be the go-to platform for all software nowadays.
Web development is about evolving software: from idea to actual requirements, from an MVP tested by your friends & family to a system used by millions of users.
Why
The internet is full of articles on âHow to create a CRUD API with Node.jsâ, âHow to configure Nginx as a reverse proxyâ or âHow to do X for Yâ.
However, I think thereâs a lack of details about why some patterns and ideologies emerged in the last few years.
What I think is missing (or maybe is only accessible via paid courses) from the general âinternet archiveâ is how parts of a system work together in the whole lifecycle of a project, and how a CI/CD pipeline serves so many uses and it allows you to deliver fast, bit-sized iterations of your software so that users can benefit from it as soon as you are done coding it.
Thatâs not an easy task.
There are a lot of trade-offs that should be considered for the long-term success of a project: from small decisions like what library to use to validate the input to architectural decisions about how to make a system elastic but cost-efficient at the same time, all the way to being able to iterate fast and donât pay 300 devs when 30 could suffice.
How I see things
Web dev is not about Javascript or Kubernetes - not only. And it certainly is not about âPHP is dyingâ vs âuse Node!â.
It is about delivering software. It has evolved and nowadays it also means delivering all kinds of software in a browser.
My hot-takes about software engineering, with a naturally biased mentality coming from web development:
- Translating the product requirements into technical ones is not enough; one should take into account actual deliverable milestones.
- It is better to throw away 2 months of work that was tested by real users than spend 6 months to âdo it rightâ.
- If you know how to test a feature or project, the actual coding is a breeze.
- Dev experience has a huge impact on
time-to-market. Devs should have an easy way to code and to prove that it works.
Yes, Iâm the kind of person that wants to get the software out the door as soon as possible. Iâm sold on the idea that software not delivered is worth 0$.
Yes, this translates into the iterative / agile approach.
I also think that moving too fast and delivering bad software is just as bad.
The problem
So⊠how? How can one move faster, and get actual software out the door (in users' browsers) when web dev nowadays means frontend*
- Backend
- CDNs
- Cloud
- 3000 javascript libraries
- Microservices
- Kubernetes
- S3 (or S3-compatible)
- Serverless
- Kafka
- Go
- Rust
- Java
- Async processing
- MapReduce
- Nginx
- Haproxy
- L4 LB
- L7 LB
- Git
- DevOps
- etc
The list can go on. The list does go on.
My contribution
The bad news : if you want to create an environment where web dev is actually productive you need each web developer to be an entire IT department.
Yes, it used to be a joke running on LinkedIn a couple of years ago.
IMO, that joke has, unfortunately, become true: it doesnât matter if you want to work as a Frontend, Backend, full-stack, DevOps, Cloud Engineer, etc.
As a âweb developerâ, you now need to understand the big picture of what delivering software in a browser means.
The good news : I donât think it is impossible.
You donât have to be a master in all areas in order to navigate through what web means.
Quite the opposite - having a general idea about how things work together is far more important than mastering only one topic.
Thatâs why I am writing down my mental model - my cheatsheet, if you will. This is what this whole âContinuous Delivery: HTML to Kubernetesâ series is about.
How
Let this be the start of a âhow to web in modern agesâ series. My rough idea of whatâs important and how to tackle it:
First, set up the basics of how the internet works:
- Delivering software in a browser - Frontend apps
- Then weâre going to look at how important it is to understand how your app is going to be deployed⊠by running it locally
- Then weâre going to set up share-able dev setups using docker-compose (work-in-progress, sorry!)
The next step is to see how one can integrate them and how to test them. How to be efficient when coding. How to deliver fast.
After we have a working PoC, we are going to scale it up using a local Kubernetes cluster and deep dive into what delivering software at scale means, while still being able to be efficient when coding.
Necessary disclaimer
It is a biased tutorial of what I think one should focus on if one wants to deliver good, scalable software, in a timely manner.
That means there will be a lot of focus on the CI/CD, testing, and understanding how & why things work in the modern world.
Closing notes
Fair warning: most likely, the plan will change while I write different articles and realize I want to write about things in a different order - or about other things altogether.
And thatâs ok because thatâs what web dev is about: delivering software before requirements or priorities change.
I would also like to get input from the community. I am open to changing my plan (see what I did there?) if I find out certain topics or areas would be of greater interest than what I initially considered. So donât be shy, say Hi đâŠ
Ok now, go on, we canât go into Kubernetes if we canât display anything in a browser. Go get familiar with web apps, because understanding the front-end is the stepping stone to understanding how everything works. Just to be clear, that statement comes from a backend dev đ
By-bye!
This content originally appeared on DEV Community đ©âđ»đšâđ» and was authored by costica
costica | Sciencx (2023-02-18T08:15:00+00:00) Continuous Delivery: HTML to Kubernetes – the why. Retrieved from https://www.scien.cx/2023/02/18/continuous-delivery-html-to-kubernetes-the-why/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.