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.
What did I miss?
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.
this user gets it
From the top of my head...
* 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.
* A bunch of devops with intentions of implementing "industry best practices and modern tooling ©" that will end up creating a house of cards in Terraform that nobody, themselves included, will dare to touch in six months down the road.
Am I sounding too cynical?
Seven red lines, two with red ink, two with green ink and the rest – with transparent. One in the shape of a kitten.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.
Never knew about this feature!