I find the simplicity of the stack brilliant. It makes me to think now, to which extent, the industry nowadays simply suffers from a mix of lack of knowledge, CV driving design and big players in the game trying to sell you overkilling solutions and approaches for their own economical benefit. Have we perhaps, fell into a big enchant and, at the end of the day, 99% of companies out there could just use a classic LAMPish kinda stack managed by 3 or 4 dudes?
I just imagined trying to sell this architecture for a new product in an imaginary company, an amalgamation of every place I have ever worked:
You have to change to Azure, because we are Microsoft partners and we have free credit.
The credit is not too much though and we have to spend the same money on useless trainings so we keep being partners.
4 core and 8GB should be plenty for your dev VMs, that’s the largest we can run on free MSDN accounts.
Have you tried the managed API gateway? Why not?
You should use managed caching on the edge.
We already have an on-prem SQL Server, use that to cut costs. Yeah it runs on Vmware and network storage.
Do we have support contracts for Nginx, Ubuntu?
We have RHEL licenses, so you should use that.
Can we run this in our OpenShift cluster instead? To cut license cost it will be co-deployed with the developer envs of other product, but just set resource limits.
Yeah, we only have NFS storage.
S3? Just use a PVC, it’s the same.
We decided on Datadog for unrelated product A and B, so you must use that.
The license is expensive, so only log errors please.
We use Kafka for the workqueue, but limited to 2 cpu cores to make it cheap, so please make sure not to send too many notifications.
Python is not for production things, we will assign an offshore team to rewrite it in Spring Boot.
We target Java 11, because our productivity increasing libraries are not yet updated.
Minor change needed for deploy: every service should build it’s own RPM package in it’s dedicated git repository.
You need to submit the architecture diagrams and service documents next week, thanks for the meeting.
The security team is getting weird reports from their internal nmap scanner that is constantly scanning this network. No, they don't know which of their vendor automated scanners are doing it, no they can't turn it off, so please add code to specifically ignore those scans.
Our VMware cluster has plenty of compute left, but it is out of storage space because there are hundreds of VMs from other teams and nobody knows what is still being used, so you can't get any more dev instances until we get more storage added to the NAS (in the next quarter's budget).
Any unrelated director somehow ended up seeing this diagram and had some "suggestions". Please implement these changes asap.
* A bunch of opinionated devs pushing for microservices because they heard that's what cool kids do now. No technical reason behind at all, just pure bias flamed by a couple of blog posts/YouTube talks they watched one evening.
Funnily enough I've never worked with a dev that thought microservices were actually a good idea as a standard solution. My last brush with it is by proxy of one of my former teammates who has a client contract where the client insisted they do microservices for their app that fits in a t2small with 90% resources to spare and will for the foreseeable future. So far it's slowed down development to probably 25% or so of the speed it was before and 10% of what it should be.
There is not way in hell, I will be able to work for such company more then 6 month (well may be it if it is 7 figures, but even then I don't think I last longer then one year), I am sorry who has to go through this.
I run a small startup. We use a monolith and docker and no kubernetes. The tech team is me and two young software engineers. I.e. I'm the only experienced person in the team. My engineers are super productive though and quick learners.
The thing is that with a small team, you need to focus your engineering efforts on things that add values, i.e. mostly functional improvements of your product. Everything else is a distraction. Anytime we hit a problem everything grinds to a halt until we fix the problem.
Non value adding activities like devops are things that we do on a need to have basis. I have used things like teraform in the past but I opted not to on this product. Reason: I'm not planning to take down my servers and recreate them. And when I do that anyway, it takes about half an hour. Not worth spending days/weeks automating. There's a reason companies employ full time devops engineers, it's actually a lot of work. I do most of the devops in my team. When I have time and when it adds value. Which is not often. I do it well and I keep it simple.
We deploy multiple times per day though; that's worth automating. Automating things you only do once just isn't. We might get around to getting some automation for setting up our infrastructure eventually. But it doesn't really solve a problem I have right now.
Like instagram, we can scale if we have to. We're in google cloud and we use a load balancer and a scaling group of simple vms that run the docker container. One nice thing in Google cloud is that you can create a vm and parametrize it with the docker container image and it will run it. No need to install anything. The default os on the vm is docker ready. So, that's one less thing for me to worry about: installing shit on vms and making sure that is updated. I simply build my docker containers, push them to the registry and tell the scaling group to apply a new instance template with the new container. It does the rolling restart. That's just 2 simple gcloud commands in a Github action.
Simple is essential. Easy to understand. Easy to fix when it misbehaves. Easy to explain to others. Simple ensures you don't waste time.
> One nice thing in Google cloud is that you can create a vm and parametrize it with the docker container image and it will run it. No need to install anything.
Agree. The state of Kubernetes increasingly reminds me of the complexity hell that is Java J2EE. It’s an ecosystem of vendors with a self interest in selling complex solutions to sell high margin consulting services on top. Thus was J2EE.
