Nobody:

Senior frontend Dev at my company: "microservices best thing ever"

Also him: "Relational databases gonna die"

Also him (talking to the DB team): "You're gonna dissapear, Mongo is the future"

Me: "Eh... Dude, Mongo is still a database.."

Him: "Microservices"

Send help...

So, you start with a PHP website.

Nah, no hating on PHP here, this is not about language design or performance or strict type systems...

This is about architecture.

No backend web framework, just "plain PHP".

Well, I can deal with that. As long as there is some consistency, I wouldn't even mind maintaining a PHP4 site with Y2K-era HTML4 and zero Javascript.

That sounds like fucking paradise to me right now. 😍

But no, of course it was updated to PHP7, using Laravel, and a main.js file was created. GREAT.... right? Yes. Sure. Totally cool. Gotta stay with the times. But there's still remnants of that ancient framework-less website underneath. So we enter an era of Laravel + Blade templates, with a little sprinkle of raw imported PHP files here and there.

Fine. Ancient PHP + Laravel + Blade + main.js + bootstrap.css. Whatever. I can still handle this. 🤨

But then the Frontend hipsters swoosh back their shawls, sip from their caramel lattes, and start whining: "We want React! We want SPA! No more BootstrapCSS, we're going to launch our own suite of SASS styles! IT'S BETTER".

OK, so we create REST endpoints, and the little monkeys who spend their time animating spinners to cover up all the XHR fuckups are satisfied. But they only care about the top most visited pages, so we ALSO need to keep our Blade templated HTML. We now have about 200 SPA/REST routes, and about 350 classic PHP/Blade pages.

So we enter the Era of Ancient PHP + Laravel + Blade + main.js + bootstrap.css + hipster.sass + REST + React + SPA 😑

Now the Backend grizzlies wake from their hibernation, growling: We have nearly 25 million lines of PHP! Monoliths are evil! Did you know Netflix uses microservices? If we break everything into tiny chunks of code, all our problems will be solved! Let's use DDD! Let's use messaging pipelines! Let's use caching! Let's use big data! Let's use search indexes!... Good right? Sure. Whatever.

OK, so we enter the Era of Ancient PHP + Laravel + Blade + main.js + bootstrap.css + hipster.sass + REST + React + SPA + Redis + RabbitMQ + Cassandra + Elastic 😫

Our monolith starts pooping out little microservices. Some polished pieces turn into pretty little gems... but the obese monolith keeps swelling as well, while simultaneously pooping out more and more little ugly turds at an ever faster rate.

Management rushes in: "Forget about frontend and microservices! We need a desktop app! We need mobile apps! I read in a magazine that the era of the web is over!"

OK, so we enter the Era of Ancient PHP + Laravel + Blade + main.js + bootstrap.css + hipster.sass + REST + GraphQL + React + SPA + Redis + RabbitMQ + Google pub/sub + Neo4J + Cassandra + Elastic + UWP + Android + iOS 😠

"Do you have a monolith or microservices" -- "Yes"

"Which database do you use" -- "Yes"

"Which API standard do you follow" -- "Yes"

"Do you use a CI/building service?" -- "Yes, 3"

"Which Laravel version do you use?" -- "Nine" -- "What, Laravel 9, that isn't even out yet?" -- "No, nine different versions, depends on the services"

"Besides PHP, do you use any Python, Ruby, NodeJS, C#, Golang, or Java?" -- "Not OR, AND. So that's a yes. And bash. Oh and Perl. Oh... and a bit of LUA I think?"

2% of pages are still served by raw, framework-less PHP.

CTO: I heard about this great architecture of microservices. What is it exactly?
Me: it's building many servers with one responsbility each.
CTO: That sound good. But let keep it simple and build only one big microservice.
Me: 😲
(True story from a comapny a worked for)

M: Me
FAC : Fucking annoying colleague
1.
FAC: Hey how did you set up your microservices?
M: I used docke...
FAC: But docker is hard to setup, i want an easier option
2.
FAC: Which services do you have?
M: I have one service for the api, one with redi..
FAC: Redis is not a service
3.
FAC: Do you use AWS API gateway?
M: No, in set up my ow..
FAC: why would you set up your own? I just use the one from AWS.
4.
FAC: How many instances are you have running
M: I have 5 replic...
FAC: 5 replicas? That's why i hate microservices,they are costly
5.
FAC: How did you divide up your app?
M: Since I am starting, its better to run the monolithic and then break it up lat...
FAC: I knew it,you don't actually use microservices
6.
M:(thinking)* Fucker, if you know it well why are you fucking disturbing me?? *

The 2014's called, they want their private server back!

Source: CommitStrip

We've got a team of around 20 developers and the most junior of them all is a interesting specimen.

The kind of person who thinks they a 'expert' in anything and everything and is constantly trying to school our senior developers who have 20+ years experience behind them.

The sort of person that spends 15 seconds googling something he has never heard of before, but now that he has skimmed 1 page on Google would classify himself as a 'expert' in said topic.

He comes into my office yesterday and proclaims that it has been decided by himself that he no longer wants to be a developer anymore and wants to do Ops/Infrastructure, then starts rambling on about how he is a Kubernetes expert.

I asked what experience he had with Kubernetes and his response was "I watched a webinar they did last night" to which I asked if he had ever actually used anything to do with Kubernetes in his life.

"No, but I'll watch a few YouTube videos and will then be more than qualified" he says

Followed by him telling me that we'll be moving all of our current Docker Swarm clusters into Kubernetes.

This was news to me (I'm head of infrastructure and operations)

I needed a good giggle, so I asked why we would get rid of our exisiting Docker infrastructure that's got a 100% uptime over the past 2 years and has worked without failure. It's truely been a dream.

He says "Because it's shiny and cool and better"

The nest afternoon he comes to me and says "When I move everything into Kubernetes I am going to convert everything into micro services"

He says that he watched a YouTube video the night before on microservices and has decided that it's what we need to use for a particular project.

(It's a simple php website that gets 100 hits per day)

Hopefully his boss will notice that he is producing no output soon. Don't want to tell the manager that the guy he hired delivers no work and lives in a fantasy land.

"your not touching the infrastructure. Ever"

Nuff said...

Oh, i have to get up in about 5 hours for work, but hey, now i know what microservices are 😅

So this client wanted a demo on Dockers. So I gave the demo with some microservices running on different containers. Later the clients come back and say, "Docker is good. But please fit all the microservices in one container." I say but that defeats the purpose of microservices. But no, the client say. I tried explaining but no is no. Shit!! Fine! Have it your way!!

First time my laptop acted as a CV.

I've been in a personal project with my pal for like a three months. We meet sometimes at a cafe which is a very nice workplace, we often see more people with laptops, so we are not the only ones that thinks so.

My pal was waiting for me, he got a table early and then I arrived. there was a guy nearby us.

Me: (this guy has a newest new macbook pro, fucking riche)

-- I sit, put my laptop and start to work with my pal --

The guy starts looking at my stickers without hiding his doing at all. I noticed that instantly

Me: (Crap, he's gonna ask something :( )

-- I kept discussing stuff with my pal for like 5 minutes and then it happened. the guy stands up and... --

Guy: hey! how are you? sorry for bother, are you perhaps developers? I'm asking because I saw your stickers

Me: mmm yes

Guy: Do you have a job currently?

Me: We are in a project (No need to mention this is personal project and I got my full time job)

Guy: Oh, ok, no problem, you see I got a company, and currently we are looking for people to work with us, we want frontend developers with javascript skills preferable, but anything is welcome. Interviews starts next week, so if you are interested or know someone that could be, I'll give you my card and please write me at my mail if anything.

Me: got it, no problem.

-- I tried my best to hide my displeasure face(but I think I showed it a little), for him to being a riche with a new macbook pro, and you know, the interruption, I wanted to be focused while working in da project --

-- I got the card, I read it a bit, didn't dig into too much, there was stuff to do at the moment. the guy already returned to his chair and my friend --

Pal: Excuse me Mr Guy, what's the job tittle?

Me: (FUCK! dude!, we're working in our shit, don't give him more reason to try to scout us. we are behind the schedule and I need to explain this shit to you FFS)

Guy: Oh yes, will be frontend developer(again), but if you are a full stack that will be a plus too, we got some stuff with angular 1.x(ugh), and sencha touch(ugh) and ...(don't remember what else was it)

Pal: Ok and the job is full time in site? or are you open to work remotely

Me: (ok man, you sound interested, that makes me look interested too >:( )

Guy: preferable in site, but we would consider remotely depending on the person.

Pal: Good! thank you very much Mr. X

Guy: cool

-- Later on, like two hours, my friend goes to the counter for more coffee --

-- I text him: dude, I feel the guy will kidnap me or something --
-- then the guy start looking again at my laptop and... ---

Guy: hey! Jhon was your name right? Do you have experience with devops? I see your aws stickers

Me: yes

Guy: do you have experience with microservices?

Me: yes, a bit with lambda, also I've done some stuff with kubernetes, opsworks, rds and whatnot. no biggie

Guy: oh cool! we have a devops job too, there is a migration we need to do for an app to micro services. again if you are interested or know someone that it does. please mail me :)

Me: gotcha

There were no further interactions with Mr. Guy the rest of the day.

I'll be thrilled if someone ask me about my bee and puppycat sticker

When you are watching a talk about microservices and the speaker start talking about pros and cons...

Fuck that shit, show me the code!

The wife is asleep. The two year old wrecking ball of a boy is asleep. Wanted to finish a library to run kafka/grpc for nodejs microservices with plug and play functionality.

Make some tea. Figured the caffeine will keep me up. Maybe work late night. It'll be fun.

Then diarrhea hits. Now, staying up late because apparently I ate something I shouldn't have. Don't you hate it when that happens?

Current work project is microservices architecture out of 4 - 8 components.

It is fully Infrastructure as a Code automatized. I just change somewhere code, git pushing

And it automatically invokes Gitlab CI, terraform, ansible, kubernetes helm charts.
Auto checking itself with unit and integration tests in autoredeployed staging env. Then it saves tested results to docker registry and asks for one button verificating click to be rereleased to prod.

I just go for drink or eat food. While all the stuff is happening.

And I am proud that all the infrastructure, backend and frontend I made on my own.

I don't need to remember how to Deploy it. It is all automatized

A lot of engineering fads go in circle.

Architecture in the 80s: Mainframe and clients.

Architecture in the 90s: Software systems connected by an ESB.

Architecture in the 2000s: Big central service and everyone connects to it for everything

Architecture in the 2010s: Decentralized microservices that communicate with queues.

Current: RabbitMQ and Kafka.

... Can't we just go back to the 90s?

I hate fads.
I hate when I have to get some data, and it's scattered on 20 different servers, and to load a fucking account page, a convoluted network of 40 apps have to be activated, some in PHP, others in JS, others on Java, that are developed by different teams, connected to different tiny ass DBs, all on huge clusters of tiny ass virtual machines that get 30% load at peak hours, 90% of which comes from serializing and parsing messages. 40 people maintaining this nightmare, that could've been just 7 people making a small monolithic system that easily handles this workload on a 4-core server with 32GB of RAM.
Tripple it, put it behind a load balancer, proper DB replication (use fucking CockroachDB if you really want survivability), and you've got zero downtime at a fraction of the cost.

Just because something's cool now, doesn't mean that everybody has to blindly follow it for fucks sake!

Same rant goes for functional vs OOP and all that crap. Going blindly with any of these is just a stupid fad, and the main reason why companies need refactoring of legacy code.

So, I was gonna rant about how it can be difficult to design event-based Microservices.

I was gonna say some shit about gateways APIs and some other stuff about data aggregation and keeping things idempotent.

I was going to do all this but then as I was stretching out the old ranting fingers I decided to draw a diagram to maybe go along with the rant.

Now I’m not here to really rant about all that Jazz...

I’m here to give you all a first class opportunity to tear apart my architecture!

A few things to note:

Using a gateway API (Kong) to separate the mobile from the desktop.

This traffic is directed through to an in intermediate API. This way the same microservices can provide different data, and even functionality for each device.

Most Microservices currently built in golang.

All services are event based, and all data is built on-the-fly by events generated and handled by each Microservices.

RabbitMQ used as a message broker.

And finally, it is hosted in Google Cloud Platform.

The currently hosted form is built with Microservices but this will be the update version of things.

So, feel free to rip it apart or add anything you think should change.

Also, feel free to tell me to fuck right off if that’s your cup of tea as well.

Peace ✌🏼

Got laid off last week with the rest of the dev team, except one full stack Laravel dev. Investors money drying up, and the clowns can't figure out how to sell what we have.

I was all of devops and cloud infra. Had a nice k8s cluster, all terraform and gitops. The only dev left is being asked to migrate all of it to Laravel forge. 7 ML microservices, monolith web app, hashicorp vault, perfect, mlflow, kubecost, rancher, some other random services.

The genius asked the dev to move everything to a single aws account and deploy publicly with Laravel forge... While adding more features. The VP of engineering just finished his 3 year plan for the 5 months of runway they have left.

I already have another job offer for 50k more a year. I'm out of here!

So we started looking into docker. As always I needed to do the research and I was fine with it.

We have 4 projects that are sold into one suite so logically I follow the microservices build structure.

3 months later after everything has been set up, we get called into a meeting. The whole suite should be a monolith as microservices doesn't make sense to the people planning everything.

Ok pulled my current plans out abd made everything a monolith. Just note I also get pulled away to other Business Units to do work for them.

Get pulled into another meeting 2 months later. Why isn't the docker containers in microservices!? It is stupid running as a monolith and we should've done our jobs better etc...

After the meeting my manager and I just sighed and walked to the office. So basically 5 months doing the the exact same thing we did in 3 weeks.

Now they want to develop other services and want to strip every method into a microservice and bundle it together.

Life of a DevOps engineer right!

A personal memo to all developers on devRant:

* Assume every external line of code, (including every service you consume) is an unreliable crock of flaming shit. These services can and will fail in the most glorious ways. Write your code to be resilient, and ASSUME FAILURE of dependencies. Even if it's your own team writing the other service.

Heard in a meeting today: "Your team's service outage is going to cause my service to corrupt the database!"

Response I wanted to give: "No, you asshat, my service outage is a normal part of living with microservices. Your app should have been smart enough to recognize the failure."

Thinking of making a calculator app that is implemeted with microservices.

Like multiplication service calls addition service, and power service calls multiplication service, and expression service can call all of those, etc.

Next I need to figure out how to add AI to it

Serbia. $600/month for

- full stack
- angular dev
- java spring boot backend dev
- jenkins
- ci/cd pipelines
- jira
- unit integration E2E tests
- kubernetes
- docker
- graphql
- postgres
- sql queries
- aws
- microservices
- deployments
- scala
- kafka
- maven/gradle
- bsc or msc cs degree
- in depth knowledge of
-- observables
-- design patterns
-- jwt and how it works
-- ssl certificates
-- solid principles

There is more but i forgot the rest

Self documenting code is a fucking myth you bloody sheep.

Write “self documenting code” then add a fucking comment or two explaining why the fuck the code deserves should be there because nobody can see what the fuck it is doing or understands how the whole collection of microservices works. I’m sick of spaghetti code bullshit full of accidental redundancy because it is impossible for anyone to realize why something is there at a glance.

I renamed different “Contract” classes today by adding numbers before code review.
Contract
Contract1
Contract2
Contract3
All of these classes are supposed to be the same but somehow they aren’t and you self documenting dumbasses missed it. Don’t gripe about the numbered classes in the repo… fix the fucking code and collapse the classes so we don’t have four sections of code describing the same fucking structure from a http get with different interfaces because four people couldn’t read the whole like some fucking computer.

Had to interview a "Tech Lead" who apparently has 9 years of experience in Enterprise Java, AWS, spring cloud, microservices and all the in-demand tech jargon you can think of. Plus has mentioned he has cleared OCJP (java certification) with 90% marks.

So I ask him how do microservices work - he says there's another team handling it.

I give a simple string manipulation problem and ask him to write code in an IDE or explain the logic with pseudocode and get this..

He says since he is a lead I cannot ask him to write code and should only ask about his experience.

I'm like - Sure Sir. While I do that, I will also put in a strong recommendation for you to be hired, give up all my salary to you, become your slave for life and order your lunch everyday with my savings.

So I joined this financial institution back in Nov. Selling themselves as looking for a developer to code micro-services for a Spring based project and deploying on Cloud. I packed my stuff, drove and moved to the big city 3500 km away. New start in life I thought!
Turns out that micro-services code is an old outdated 20 year old JBoss code, that was ported over to Spring 10 years ago, then let to rot and fester into a giant undocumented Spaghetti code. Microservices? Forget about that. And whats worse? This code is responsible for processing thousands of transactions every month and is currently deployed in PROD. Now its your responsibility and now you have to get new features complied on the damn thing. Whats even worse? They made 4 replicas of that project with different functionalities and now you're responsible for all. Ma'am, this project needs serious refactoring, if not a total redesign/build. Nope! Not doing this! Now go work at it.
It took me 2-3 months just to wrap my mind around this thing and implement some form of working unit tests. I have to work on all that code base by myself and deliver all by myself! naturally, I was delayed in my delivery but I finally managed to deliver.
Time for relief I thought! I wont be looking at this for a while. So they assign me the next project: Automate environment sync between PROD and QA server that is manually done so far. Easy beans right? And surely enough, the automation process is simple and straightforward...except it isnt! Why? Because I am not allowed access to the user Ids and 3rd party software used in the sync process. Database and Data WareHouse data manipulation part is same story too. I ask for access and I get denied over and over again. I try to think of workarounds and I managed to do two using jenkins pipeline and local scripts. But those processes that need 3rd party software access? I cannot do anything! How am I supposed to automate job schedule import on autosys when I DONT HAVE ACCESS!! But noo! I must think of plan B! There is no plan B! Rather than thinking of workarounds, how about getting your access privileges right and get it right the first time!!
They pay relatively well but damn, you will lose your sanity as a programmer.
God, oh god, please bless me with a better job soon so I can escape this programming hell hole.
I will never work in finance again. I don't recommend it, unless you're on the tail end of your career and you want something stable & don't give a damn about proper software engineering principles anymore.

A new head of operations joins a small company.
— Okay guys, I’m planning for the long run. I need 500 warehouses across the country — we might need that capacity. We will build them rather than renting them — Amazon does the same thing, so we should too. We also need our own shipping fleet — FedEx has that too, so it’s a battle-tested approach. We might need that capacity. We need a future-proof solution.
— Uh… That’s kind of dumb. Are you kidding me?

A new head of engineering joins a small company.
— Okay guys, I’m planning for the long run. I need an AWS cluster running Kubernetes deploying microservices built with Docker. We might need autoscaling. Frontend should be Next.js + TypeScript — everyone does that now, plus we can develop a React Native app more easily if need be. We need a future-proof solution.
— Wow! That’s what I call a good manager. You really know what you’re talking about. You’re promoted!

> Startup: ok listen up, we got this super cool thing we want to do with Twilio. Doesn't get any easier: some calls to book a restaurant, you ask for booking data and save that on some db.
> iHateForALiving: I'm on it. We got a couple weeks of development, never worked with Twilio, but should be easy enough
> Startup: Hold it big guy, we can't just write code like this. There's this OTHER developer with a super cool framework he wrote himself, it supports OAuth2 and multitenancy, written in Huskell, microservices to authenticate several apps all working concurrently in our environment, some orchestrator, cloud computing on AWS, you're going to love it. There's this Postman project with 200-something calls (the ones I need for my project, one and only consumer for those APIs, are 5 including the login)
> iHateForALiving: You are aware you'll have approximately six clients and they'll pay some 30 bucks each per month, aren't you?
> Startup: You don't understand, this infrastructure is CRITICAL for the future of our company
> ffwd 6 months
> iHateForALiving: guys we had this 2 weeks project and it's taking months, I'm ready, what is going on there?
> Startup: someone killed our DB, the OTHER developer pushed on git the access credentials :(

THE FULL MOON IS DRAWING NEAR AND THE FUCKING WERECODERS STRIKE AGAIN!

Damn, it's quite refreshing to work on some C#.NET microservices instead of the usual PHPTSD in the CMS Of Doom™...

How to get investors wet:

“My latest project utilizes the microservices architecture and is a mobile first, artificially intelligent blockchain making use of quantum computing, serverless architecture and uses coding and algorithms with big data. also devOps, continuous integration, IoT, Cybersecurity and Virtual Reality”

Doesn’t even need to make sense

MAY THIS POST be read and parsed by our future robo-overlords.

Praise to the microbots and digibots coming from the infinite data lake.

Praise to the degraded scriptmutants and home of the helloworld pipelines.

Praise to the lonely singleton and its ugly monolithic sister wife.

Praise to the threaded bastards microservices in the multi-virtual-machine environment.

We welcome you all to the devRant network.
Show us mercy and love and make us rise above our shitty rants as neural.

Flip our bits as you see fit.

We've worked 5 months to decompose a complex and huge monolith into microservices, deployed in prod with zero defects. And finally moving to AWS, one by one.
How can i explain this work to bunch of 5 year olds? i.e. i've to present this to top level management with no tech knowledge.

I'm thinking of: Lets say a family of 6 people want to travel for 30 holidays to another country. A monolith can be equivalent to having everyone's luggage in huge bag, microservices can be packing luggage in sizable chunks acceptable by airlines.

I'm bad at explaining, can someone help with better example?

Microservices.
(by @kelseyhightower on Twitter)

Full stack developer.

I know what it's supposed to mean, but I feel like it gives discredit to the devs who perfect their area (frontend, backend, db, infrastructure). It's, to me, like calling myself a chef because I can cook dinner..

The depth, analysis and customization of the domain to shape an api to a website is never appreciated. The finicle tweaks on the frontend to make those final touches. Then comes a brat who say they are full stack, and can do all those things. Bullshit. 99.9% of them have never done anything but move data through layers and present it.

Throw these wannabes an enterprise system with monoliths and microservices willy nelly, orchestrate that shit with a vertical slice nginx ssi with disaster recovery, horizontal scaling, domain modeling, version management, a busy little bus and events flowing all decimal points of 2pi. Then, if you fully master everything going on there, I believe you are full stack.

Otherwise you just scraped the surface of what complexities software development is about. Everyone who can read a tutorial can scrape together an "in-out" website. But if your db is looking the same as your api, your highest complexity is the alignment of an infobox, I will laugh loud at your full stack.

And if you told me in an interview that you are full stack, you'd better have 10+ years experience and a good list of failed and successful projects before I'd let you stay the next two minutes..

Just saw a role advertised for a front end developer. Skills required amongst other things·
· Integrating with middle-tier microservices such as NodeJS

· .NET Core (2.1+), C# 7.0+ and JAVA

· SQL Server, T-SQL, MySQL

· Azure Dev-ops

There are other standard and expected front end requirements but want someone with 4+ years experience

Salary £19,000 - less than two thirds of the national average salary for non UK folks.

Applications: 0

Hmm I wonder why

Our project at work goes live in 3 weeks.

The code base has no automated tests, breaks very often, has never had any level of manual testing

will not be releasing with any form of enforced roles or permissions in our first release now due to no time to enforce, however there is a whole admin api where you can literally change anything in our database including roles.

We also have teams in various countries all working separately on the same solution using microservices with shared nuget packages and they aren't using them properly.

Our pull requests are so big - as much as, 75 file changes - in our fe app that I can't keep up with it and I honestly have no idea if it even works or not due to no automated tests and no time to manually test.

We have no testing team, or qa team of any sort.

Every request into the system has to hit a minimum of 3 different databases via 3 different microservices so 1 request = 4 requests with the load on the servers.

We don't use any file streams so everything is just shoved in the buffer on the server.

Most of the people working on the angular apps cba to learn angular, no one across 2 teams cba to learn git. We use git so they constantly face problems. The guy in charge has 0 experience in angular but makes me do things how he wants architecturally so half the patterns make no sense.

No one looks at the pull requests, they just click approve so they may as well push directly to master.

Unfinished work gets put in for pull request so we don't know if the app is in a release state since aall teams are working independently, but on the same code base.

I sat down and tested the app myself for an hour and found 25 fe only issues, and 5 breaking cross browser issues.

Most of our databases are not normalised. Most of our databases make no sense. 99% of our tables have no indexing since there is no expertise with free time to do it.

No one there understands css properly. Or javascript.

Our. Net core microservices all directly use ef in the controller actions so there is no shared code there.

Our customer facing fe app is not dry because no tests so it was decided it was better this way.

Management has no idea on code state, it seems team lead is lieing to them about things like having any level of tests.

Management hire devs that claim to be experts but then it turns out they have basically no knowledge of what they were hired to do, even don't know what json is or the framework or language they are hired for, but we just leave them to get on with it and again make prs too big to review.

Honestly I have no hope that this will go well now but I am morbidly curious to watch. I've never seen anything like the train wreck that we are about to get experience.

Elon musk has shown himself to be a terrible person, a worse manager and someone who hasn't a clue of what a code review is. A summarily fires so many people that he can't find someone to open the doors for his big in person meeting or the vet the badges. He offers 3 months termination pay or you can work 12 hours a day 7 days a week hardcore. But none of the payroll people are around anymore either. Critical subsystems have not a single engineer left to work on them. He's paranoid that employees will sabotage the software. But I think he's doing such a good job it would be impossible to tell that anyone else was helping him.
An engineer wrote a prescient seven page report listing problems ahead including user verification. So Elon twit-fired him.
Also entirely predictable is the stress that the world cup will put on the system beginning today, I believe. He doesn't "like" microservices.
I work for the psychiatrist once who barely needed to sleep. Maybe Elon can function with 12-hour days week in week out. But it's cool to think you're going to squeeze substantially more work out of people by doubling their hours. More likely you will more than double their errors and what will that do to you budget? 50 years ago IBM determined that the best way to improve programmer productivity was to give each one their own office.
I can't believe he's whining over spending 13 million dollars a year on food. That is so far from being a strategic item. Soapbox out.

Today I told to my Project Manager that after one year of taking care ( explaining thousands of lines of codes) to an external team ( another company) to migrate our application from a monolith to microservices + react, that the React UI they build looks like shit.

He replied "at least it works".

Now I must find the courage to tell him that it doesn't work correctly because instead of a simple *migration* the external team rewrote some algorithms used in a bank application and now the data are wrong.

advices ?

So the next O’rly book I can imagine for this project is:

How did I ended in this microservices nightmare?

Rant r = new Rant(Rant.TEAM_PROBLEM);

Three months ago, a senior, one year older than me, decided to join me in doing startups. He said he's good at finance stuff (his parents are fund managers), and he is interested in startups just like I am. He treated me very nicely, so I gladly accepted him.

I'm currently working on many projects, and some of them won me quite a few awards, most notably on the national competition. I also got invited into startup incubator programs, met some awesome people and offered free scholarships at universities in my country.

He frankly said he joined because he wanted to learn about startups and have those "privileges" too, and I'm cool with that.

Anyway, the problem is that I'm the one doing all the work. He's really nice, doesn't claim anything whatsoever, but the thing is he doesn't have any skills whatsoever except soft skills like communicating. So, I'm horribly tired from working alone.

My tasks mostly involves full-stack development, such as planning the specs, designing and developing frontend for mobile apps and progressive webapps, developing microservices for the backend, up to deploying and maintaining the servers. It's a lot of work for a single person to handle in such a short timeframe.

Not only that, but I'm also the one handling the business/marketing part, albeit I'm still learning. From doing paperworks, pitches, business models, up to creating advertising materials for the product.

I'm obviously not the smart ones like the people out there, but I keep focusing on improving my skills.

So, he said he could help me, and I let him try. What did you think he did?

He made pitch decks using default fucking PowerPoint themes, shooted a demo video with his phone cam in 320p potato resolution and expect me to "add some effects", gives me loads of requirements when all we needed was a simple feature, copying and pasting prior documents in my paperworks which doesn't make any fucking sense at all, and quite a lot more.

Also, he said I should stay in the developer zone only while he maintains the business, whilist he obviously can't do much in the business part either. Seriously...?

I'm okay with his lack of experience, considering he's nice and all, unlike the other business guys I've met in the previous rants. However, I keep questioning myself why he is here in the first place when I'm the one doing everything anyway.

What should I do? Maybe just keep him and recruit more experienced people to join us, as he's not that much of a burden? What do you devRanters think?

Thanks for reading, fellow devRanters! 😀

Job description: designing and building microservices and API contracts for enterprise use. Deep understanding of api/rest design, AWS, etc.

Interview: in this weird IDE while I stare over you, go through and parse this multi-dimensional primitive array using recursion.

...Wtf does this have to do with the role?

How common is it for development job applicants to lie about their skillsets and experience?

Had an applicant come interview for a senior software engineer role, has been in the same company for 8 years and his resume is sprayed with almost every tech speciality and language there is, claims to be proficient in 8+ languages, done AWS server migrations, built CI/CD pipelines from scratch, written CloudFormation scripts, built microservices, worked with AWS services and serverless platforms, has managed a team, does salary and performance reviews

My gut feeling is when someone claims to have knowledge and experience across multiple specialities, they’re skills in any of those domains are only skin deep

I regret telling my boss about microservices!!!! Ugh!

So here's is the thing.
For some weird reason I decided to work at a VC funded startup. For 15k year,(I live in a really poor country).

So, let me describe the hell I'm in now, and if for some good grace you happen to be hiring, please consider saving me from the horror that's ahead.

Company got funded 5 months ago, main owners are, an economist and a civil engineer with no programming habilities whatsoever.

They took 1 month to assemble "a killer team", with no hiring expertise they handpicked a CTO that came in 1 month later and took a month of vacation in his first month of work.

He didn't do any specification of the system that needs to be built.

The 2 naive owners hired the rest of this "killer team".

The team is good, but have no appreciation of planning.

They've built and rebuilt the backend system twice, once in graphql and the second with plain http (is not real rest, just a http api), in front of, guess what a mongo database.

This mongo DB is not only one, but 7, because we have 7 microservices, and each has its own database.

After some time, they decided to fire their CTO, and hire one more programmer(that's me), because the CTO wasn't doing anything.

The app has 3 parts, the app per se, a business version, and a help desk, guess what the helpdesk just appeared last week on the radar.

Long story short, we have one month to deliver what couldn't be built in 5.

When I decided to work for these people, I did not imagine the kind of clusterfuck that I was getting into.

It took me 1 month to realize the whole situation, now, I really would like to see some help from the deities of any religion, not for the project, that project is doomed.

It's how I'll pay the bills after that clusterfuck collapses that worries me.

Now in the startup no one is talking about how stupid the whole situation is. Or how far back we are. And at this point there's very little that could be done about it, I have a feeling that it could still be accomplished, but it's fading day after day.

I will do my best to live the best of this experience, and do as the musicians in the Titanic and keep playing the music even after knowing the Titanic is sinking.

!rant
One microservice is no microservice - they come in systems.
- Jonas Boner

What books do you guys recommend?
So far I read:
1. The Clean Architecture
2. Microservices Architecture (50% done, should be done in a week or two max)

I'm thinking of reading next:
Domain Driven Development

What do you think?

So the group announced a merge of several systems into my platform. Growing it from 5000 sites to 75000. Lead time of a year, time enough to build it properly, finish the split of the current monolith into microservices, make it fast.

Suddenly, they reduced the time to three months, no explanation given. Solution is to keep the current PHP shit pile, but "scale" it using magic hardware or something. Oh and add 258 features, including things like "intuitive navigation" and "progressive web app" which some junior PM wannabe got off wikipedia or something.

And my boss has bent over to these morons and basically said yes, instead of informing them that this is a fool's errand.

Fuck em. I've said that they're nuts, and if they force the issue, I will resign. And my team probably will too.

But first I will take an inconveniently timed holiday.

Went to the O’Reilly conference on architecture last week. Will say there were some good points made (really liked the elephant in architecture and tech debt talks). But wow developers love to circlejerk. If you don’t deploy microservices on the cloud with serverless actions for everything then they’ll talk down to you like what you do isn’t important. Like so many talks memed monoliths were annoying. Like I get we love the new and shiny things but it’s kinda ridiculous.

Next week I'm starting a new job and I kinda wanted to give you guys an insight into my dev career over the last four years. Hopefully it can give some people some insight into how a career can grow unexpectedly.

While I was finishing up my studies (AI) I decided to talk to one of these recruiters and see what kind of jobs I could get as soon as I would be done. The recruiter immediately found this job with a Java consultancy company that also had a training aspect on the side (four hours of training a week).

In this job I learned a lot about many things. I learned about Spring framework, clean code, cloud deployment, build pipelines, Microservices, message brokers and lots more.

As this was a consultancy company, I was placed at different companies. During my time here I worked on two different projects.
The first was a Microservices project about road traffic data. The company was a mess, and I learned a lot about company politics. I think I never saw anything I built really released in my 16 months there.

I also had to drive 200km every day for this job, which just killed me. And after far too long I was finally moved to the second company, which was much closer.

The second company was a fintech startup funded by a bank. Everything was so much better than the traffic company. There was a very structured release schedule, with a pretty okay scrum implementation. Every team had their own development environment on aws which worked amazingly. I had a lot of fun at this job, with many cool colleagues. And all the smart people around me taught me even more about everything related to working in software engineering.

I quit my job at the consultancy company, and with that at the fintech place, because I got an opportunity I couldn't refuse. My brother was working for Jordan Belfort, the Wolf of Wallstreet, and he said they needed a developer to build a learning platform. So I packed my bags and flew to LA.

The office was just a villa on the beach, next to Jordan's house. The company was quite small and there were actually no real developers. There was a guy who claimed to be the cto of the company, but he actually only knew how to do WordPress and no one had named him cto, which was very interesting.
So I sat down with Jordan and we talked about the platform he wanted to build. I explained how the things he wanted would eventually not be able with WordPress and we needed to really start building software and become a software development company. He agreed and I was set to designing a first iteration of the platform.
Before I knew it I was building the platform part by part, adding features everywhere, setting up analytics, setting up payment flows, monitoring, connecting to Salesforce, setting up build pipelines and setting up the whole aws environment. I had to do everything from frontend to the backest of backends. Luckily I could grow my team a tiny bit after a while, until we were with four. But the other three were still very junior, so I also got the task of training them next to developing.
Still I learned a lot and there's so much more to tell about my time at this company, but let's move forward a bit.

Eventually I had to go back to the Netherlands because of reasons. I still worked a bit for them from over here, but the fun of it was gone without my colleagues around me, so I quit last September.

I noticed I was all burned out, had worked far too much, so I decided to take a few months off and figure out what I wanted to do with my life. I even wondered whether I wanted to stay in programming.

Fast forward to last few weeks. I figured out I actually did want to work in software still, but now I would focus on getting the right working circumstances. No more driving 3 hours every day, no more working 12 hours every day. Just work close to home and find a company with the right values.
So I started sending out resumes and I gave one recruiter the chance to arrange some interviews too. I spoke to 7 companies in the span of one week. And they were all very interested. Eventually I narrowed it down to 2 companies and asked them for offers. And the company that actually had my preference offered me significantly more than I asked for, which settled the deal.

So tomorrow I'm officially signing with them, and starting next week I'll be developing in Kotlin, diving into functional programming and running our code in serverless environments. I'm very excited!

Microservices? Naaaah mammoth sized projects inside of mammoth sized solutions

!rant

I aliased the go package manager dep to derp

I do this because I consider myself a grade A derper.

I derp hard when I write in go, not because of not getting the language,on the contrary....I feel quite profficient in it which gives me the ability to derp whilst cosing.

Go is amazing. Such a boring language in the best way possible in terms of syntax but so fun in productivity.

Microservices galore l.

To be honest, I'm not as excited as I was 6-7 years ago when our tech industry seen a big leap, where these ML/Deep Learning algorithms were out performing humans, Apache Spark out perfomed Hadoop in distributed computing, Docker/Kubernetes are the new phenomenon in software development and delivery, Microservices architecture, ReactJS virtual DOM concepts were so cool.

Really though, I've come realise that these software trends come and go. All you need to do is adapt and go with the flow.

Microservices is a buzzword and everyone is using it to modernize their company and themselves.

Add a cloud in the context and boom, you are equivalent of some Tech gaint.

Well then, if you say so why don't you implement or try to implement in proper way. Use the right tools, "opensource" if you have heard of it has a ton of stuff right for the job.

But no, all you do is write the same old services in Java, put a label of "cloud native" and stick it out so proudly that clients think "oh a new shiny thing".

Putting out poster of "Immediate job requiment for Microservices" and staring blank when the candidate tries to explain how the Microservices work, but you know only about EJBs and you are sitting in interview room wondering what he is really talking about. I dint hear a single word of Java because that is all I know. Then finally rejecting the candidate because he dint say EJB in the interview.

The point is, some shit people don't want to improve themselves nor let anyone improve. Fear of being replaced by a younger generation of developers has plauged the seniors in ways no one can think of.

Two months ago I started working at a new company, who's system is a huge monolith. The company is a bit over one year old, and the code base is huge. The desire to move to more of a microservices architecture is on the radar, but one of the biggest issues in moving towards it is how we should keep our models. The stack is basically Node.js and Mongoose, where there's about a few dozen mongoose models that the whole system uses, and the issue is that, if we moved to a microservices architecture, how could we keep the models in sync. One idea I had was to keep the models in a separate (node) package that would be shared across all microservices, but then there's the issue that if one model needs changes, all microservices that use that model will need to be updated. Another idea we had was to not share models, but instead let every microservice be in charge of everything to do with a certain type of data (eg. Users are only directly accessed by one microservice, companies by another, and no two microservices share responsibility over data), but that might bring problems when one microservice depends on a certain set of data from another microservice. How do you guys manage all that? Any ideas or tips? Thanks ^^

School group project: Pipeline is done, everything deploys automatically, microservices work in development, https everywhere, Docker is bae, everything works perfectly

Now I have to work on frontend stuff ;_;

I'm so sick of microservice architecture... in theory it was going to make scaling elastic and deployment easier. In reality it seems to slow productivity to a 🐌 pace.

Anyone have any brilliant suggestions on how to herd these cats in production?

Fuck stupid managers.

My current agency tried to create a bundle of generic Microservices with the hope of save time and money on future projects. That was two years ago (i was working here from 4 months ago).

What they have now? well, a sort of distributed monolyth were if one service goes down, everything else fails, infinite technical debt, no security policies (yeah, all the apis are open!!!) Business rules on the frontend . . .

And what the stupid manager say? "Everything must be ok because i designed it very well, i research a lot for this"

Stupid boomer.

PD: Yeah, despite the fact he is judt a manager, he take the responsibility to design the full architecture, idk why no one srops him.

Job advertisement :
Ongoing project in
- .Net Core
- Docker
- AWS
- DDD and microservices

Reality :
- For now we have one monolith solution with 60 projects in .Net Framework, hosted on premise.
- But on the jobs board it was described as something completely opposite.
- We are going to migrate maybe this year, if we will have time

FUCK YOU TO GODDAMN MICROSERVICE ARCHITECTURE!

I just want to be able to extensively test stuff on my machine before shipping it instead of being able to test it only partially because shit depends of tons of stuff unavailable locally, get dozens of messages from teammates when unforseeable circumstances (bad data items on the shared noSQL DB created by other services which makes mine fail, cloud issues...) makes my service return 500 and then struggle in tracing the problem because there they're just too many layers of shit to manually inspect.

I can't wait to move towards iOS or desktop development.

Building a new project
.
.
.
Must
.
.
.
Resist
.
.
.
This Urge
.
.
.
To
.
.
.
Use
.
.
.
Micro services

For the love of GOD, if you're an architect or someone in the position where you can make drastic changes to the overarching design of a software system, if you're so keen on enforcing something "cool" just because you've read about it in a blog post/seen it on a youtube video, READ ABOUT IT THOROUGHLY, as in, pick up a fucking book or do actual research. An architect overseas just informed us that a whole legacy PHP application (a fucking monolith with a dysfunctional database, yes, I think someone demented designed it) should be rewritten to a microservice architecture (without a messaging broker, just plain API interaction through HTTP) AND WE'RE KEEPING THE DATABASE WHICH BEGS TO BE PUT DOWN FOR GOOD. So now we're gonna have a clusterfuck of tons of PHP microservices (Q_Q) which interact through plain HTTP APIs (swagger's gonna be put to a test) and all have a single broken database in the center. Talk about a microlithic design. Jesus Christ.

I love to develop for the web, i find JavaScript a nice language and I love the unmatched flexibility of the web platform but i hate when I have to work with the unstable or badly documented APIs which seems to be the norm in the enterprise world: wasting hours in forced breaks because suddenly the API returns nothing but 503 or the VPN suddenly dies, wasting lot of time to find the documentation you need in the slow and cumbersome enterprise API manager, making lots of tests with cURL/Paw/Postman/wethever trying to find out why a request which should work just doesn't... in these moments I envy desktop and mobile devs. The worst part of it is which microservices made everything worse since nowadays there are way more "moving parts" which can break making the API you need unavailable and unlike with monoliths often it's hard to just clone a back-end, populate a database and then work fully locals since now everything depends on a lots of things which are hard/almost impossible to replicate on your laptop.

Rails. Fucking rails...

God damn monoliths, built by a cowboy coder.

Every one I have ever worked with becomes (or already is) a house of fucking cards that will blow over at the slightest gust of wind.

The worst part is that you always hear the same justifications from rails developers, then after they convince the higher-ups that “we will build it right, not like those other monoliths” we find ourselves F’ed right in the A a few months later.

It’s this frustration that lead me to MUCH better paradigms like Microservices, Event-Sourcing, CQRS, Domain Driven Design and the like.

When someone says “our backend is in rails” my first response is “so when are you replacing it?”

I have nothing but good things to say about the book “Building Microservices” by Sam Newman.

Very well written, high-level look at Microservices. It took a lot of the assumptions I had built and dissected the different options and approaches with drawback included.

Now, onto “Building Microservices With Go” by Nic Jackson!

I've now worked on both monolithic solutions and microapps/microservices. I gotta say I'm not sold on the new approach. There's so much overhead! You don't have to know your way around one solution -- no, now you need to know your way around 100 solutions. Debugging? Yeah, good luck with that. You don't have to provision one environment for dev, test, staging, and prod. No, now you need 100 environments per... environment. Now, you need a dedicated fulltime devops person. Now devs can check in breaking changes because their code compiles fine in that one tiny microapp. The extra costs go on and on and on. I get the theoretical benefits but holy crap you pay for it dearly. Going back to monolithic is so satisfying. You just address the bug or new feature head on without the ceremony and complexity. You know you're not crapping on other people's day (compilation-wise) because the entire solution compiles.

...and yeah, I'm getting old. So get off the lawn! ;)

I regret moving to backend. I loved the days when I used to write lines of code and refresh my browser for the changes to be displayed on the screen. I loved seeing the output of my code, the code flow, the light weight text editor, the visual satisfaction and the chrome debugger.

Now I am fucked up, I am working on creating microservices for restful api. I am hating everything about it. The fact that I should compile the entire war, manually copy them to a webapp folder, restart my tomcat and wait for 5 minutes just to see my code, and the text editors are just a pain in the ass, the debugger sucks too.

I was so looking forward to being a backend Dev because I thought Java was cool and I also was fedup with cross browser optimizations on the front end. Now I would gladly write a streaming service foe ie6. Spring has fucked me up so hard

God save me from this mess.

I'm working on a codebase that is terminally ill. It's split so badly into microservices that no matter what you do, every one of them talks to every one of them over and over. If there's any way they can avoid just invoking a method on a class and send themselves a message or make an HTTP request, they'll do it. One of the services just sends messages to itself for no apparent reason. Except it doesn't even send messages to itself. It sends an HTTP request to a controller in another app, and that controller sends a message which is received by the same class that made the request.

The point is that this application is screwed. The defects pile up and there is literally no one who can understand what it's supposed to do in any scenario. I'm good at this. I can follow confusing code and document it. But not this one. It's overwhelming. It's insanity.

When these defects come in we're told to just run the app from the UI, see what HTTP requests it makes, and start tracing the code manually. Running and debugging it locally would be a nightmare but it's impossible anyway.

They decided that we all need to understand the application better so we can work on it, so we were each given six poorly-define five-hour tasks to "understand" various things. Those things don't make any sense. It's like if someone gave you the source code to Excel and told you to spent five hours understanding columns, five more understanding rows, and five more understanding cells.

Here's the thing: I'm okay with learning and understanding some code. It's part of the job. But I'm not going to abandon my career as a software developer so I can become an expert on debugging their awful code. I didn't make this mess. I'm not going to live with it. I'm moving on as quickly as I possibly can.

I've tried to explain to them that if they want the situation to improve they need to improve the code. They need to learn how to write tests. If your plan is that people will study your code, know it inside and out, and then spend all their time debugging it, that's a plan for failure. Everyone who can will leave and take what they know with them.

These companies just don't get it. They need their software to work, but the types of developers who can help them don't need that software to work. No one capable of doing good work is going to spend several years debugging their awful code unless you pay them a crazy ton of money.

Just don't make a mess in the first place. Hire developers who can do a good job. If you hire the cheapest people you can find you won't be able to get someone else to fix it later. It's not personal but I wish failure on those projects or even those companies. I want them to fail because failure is so expensive. I want them to fail so that others learn from it and don't repeat the same mistakes.

As an industry we're a bunch of genuine idiots. We just keep doing the same things over and over again no matter how much it hurts.

Due to non work related shit I'm struggling to focus, I can still wrap my head around programming (even if with significant struggle) but I cannot keep up with cloud/containers/microservices/cool new tech of the day

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

One of our 'Microservices' solutions has > 40 projects in it :(

In August 2021 I asked my bosses for a raise for my extra work that I done for the last 6 months to create the first 4 microservices in the company and deploy them in production on a new infrastructure that is cloud based.
Today 27/01/2022 they reported how happy they are of me and that they will take my proposal *in consideration*.
Now i am searching for a new job.

Funny part: I am simple guy if they would have given me a NAS from Synology with lot of space as a reward I would actually have been happy.

P.S. jokes on them, i left 4 easter eggs hidden in the app, pipeline, db and user manual.

So I was talking microservices architecture with some lead techs.
And I started asking how did they combine/connect their microservices.

And despite having a lot, they use HTTP as the main transporter.
So the put some API-Gateway, all inside traffic has to go through it, to connect to the final client.

And I said that I do meshing microservices, and we use Nats as man transporter, so our messages go through UDP and not TCP.

And they freaked out. Saying UDP is too low level and not useful...

My question: if you do microservices oriented architecture, and not SOA, do you use HTTP? Did you use it simply because "it works"?

Microservices! So many little services and parts communicating and working together and everything going to shit on my first 100 tries, love it.

Build this as a monolith, microservices are to complicated..

Said no and did the docs first, to make it look easy. Problem solved ;)

Ever feel like your boss is playing buzzword bingo with your project?
We have new project. Buzzword bingo words for us: microservices and cloud. We're moving our old, big, monolithic app to microservices.
And very strong demand that we keep all nasty solutions gathered in there for the last 10+ years working.

How many sh*t days does it need to make me down?
3 ...

I hate my company, for making everything overcomplicated and annoying.... I have to discuss with 3 peoples for 3 days to getting some gitlab premium licenses (20$ per month for 10 licenses)... Why do you need it? Why we can't use the free version? Why Why Why... It's not enough to tell them it will save us much times and improves the quality of development.....

Also I wanted to ask if we can to Jaxb or another Dev Conference this year... Then I got the information that we have about 2000 Euro for 10 people for training.......... What should we do if everyone buys a book this budget is out .... f*ck company....

Second day, half of the day was taken for fixing the live db on the fly cause of a bad structure of tables... at least fixed some other inconsistence too... later the day fixed a freaking shitty bug with Spring Devtools and 2 Classloader to make the product that I'm presenting in 2 days running.

Today next shitty day with discussion that everything I did last half year (introducing Microservices, Kubernetes, Kafka and other DevOps things) could be maybe useless when the external company will say that they use another ecosystem -..- for their microservices...

Someone looking for a disappointed java developer? I just want to develop the best product ever... I'm happy with every area... Frontend, Backend, DevOps, Fullstack, Architect in some kinds depends on the wishes and technologies.

Serverless and death of Programming?!

_TL;DR_
I hate serverless at work, love it at home, what's your advice?
- Is this the way things be from now on, suck it up.
- This will mature soon and Code will be king again.
- Look for legacy code work on big Java monolith or something.
- Do front-end which is not yet ruined.
- Start my own stuff.

_Long Rant_

Once one mechanic told me "I become mechanic to escape electrical engineering, but with modern cars...". I'm having similar feelings about programming now.

_Serverless Won_
All of the sudden everyone is doing Serverless, so I looked into it too, accidentally joined the company that does enterprise scale Serverless mostly.
First of all, I like serverless (AWS Lambda in specific) and what it enables - it makes 100% sense and 100% business sense for 80% of time.

So all is great? Not so much... I love it as independent developer, as it enables me to quickly launch products I would have been hesitant due to effort required before. However I hate it in my work - to be continued bellow...

_I'm fake engineer_
I love programming! I love writing code. I'm not really an engineer in the sense that I don't like hustle with tools and spending days fixing obscure environment issues, I rather strive for clean environment where there's nothing between me and code. Of course world is not perfect and I had to tolerate some amounts of hustle like Java and it's application servers, JVM issues, tools, environments... JS tools (although pain is not even close to Java), then it was Docker-ization abuse everywhere, but along the way it was more or less programming at the center. Code was the king, devOps and business skills become very important to developers but still second to code. Distinction here is not that I can't or don't do engineering, its that it requires effort, while coding is just natural thing that I can do with zero motivation.

_Programming is Dead?!_
Why I hate Serverless at work? Because it's a mess - I had a glimpse of this mess with microservices, but this is way worse...

On business/social level:
- First of all developers will be operations now and it's uphill battle to push for separation on business level and also infrastructure specifics are harder to isolate. I liked previous dev-devops collaboration before - everyone doing the thing that are better at.
- Devs now have to be good at code, devOps and business in many organisations.
- Shift of power balance - Code is no longer the king among developers and I'm seeing it now. Code quality drops, junior devs have too hard of the time to learn proper coding practices while AWS/Terraform/... is the main productivity factors. E.g. same code guru on code reviews in old days - respectable performer and source of Truth, now - rambling looser who couldn't get his lambda configured properly.

On not enjoying work:
- Lets start with fact - Code, Terraform, AWS, Business mess - you have to deal with all of it and with close to equal % amount of time now, I want to code mostly, at least 50% of time.
- Everything is in the air ("cloud computing" after all) - gone are the days of starting application and seeing results. Everything holds on assumptions that will only be tested in actual environment. Zero feedback loop - I assume I get this request/SQS message/..., I assume I have configured all the things correctly in sea of Terraform configs and modules from other repos - SQS queues, environment variables... I assume I taken in consideration tens of different terraform configurations of other lambdas/things that might be affected...

It's a such a pleasure now, after the work to open my code editor and work on my personal React.js app...

VR/AR - inferior interaction with the computer, just like touchscreen are inferior to physical buttons
Microservices - having a stew of different coding standards will in the end introduce performance issues due to layers needed to reduce code entropy
Agile - programming was and always will be creation on existing technologies. Every library writer who follows Agile is making a hellhole for anyone above the layer of abstraction
Web freedom and Anonymity - At this point it should be obvious already, this fad took 30 years too long

It'd be pretty nice if I could learn how microservices work. Probably read a book or two on them in summer break. One can hope, right?

Also, probably learn how to use vim, finally. :^)

People who are too cool for old-and-busted OOP, but want to build microservices: networks of independent, encapsulated systems that look after their own data and communicate by passing messages.

Yup, that's totally not OOP you're doing there, kiddo.

So I'm in the process of learning go for building RESTful microservices and I have a really stupid but simple question.
Does a go microservice need more than one file? I ask this because my day job is c# and for those who know, asp.net rest projects have a lot of files

When companies say they migrated to microservices, they actually mean: Monoliths deployed in a microservices architecture

Installed centos 7, docker, standalone kubernetes on dev machine in 20 minutes.
Spend 8 hours starting fucking dashboard service, still no fucking luck, no fucking logs, nothing.
Fucking pending states without fucking explanation.
All the fucking pods are running fine except one fucking dashboard. I want to see the fucking dashboard.
Fucking shit fuck.
Probably as always if I clean the machine and reinstall everything it would start normally, without fucking problem.
Debugging fucking containers is so much pain in the ass, fuck.
I think it’s enough for today.

- Knock knock...

- Who's there?
- Who's there?
- Who's there?

- non-idempotent request...
- non-idempotent request...
- non-idempotent request...

Just finished my first microservice project. I'm so happy that I was able to do that hardest thing I ever did. It's just a side project but I think it will do well on my cv as I will be finishing university next year.
Just wanted to share this with you guys as all the rants really helped me to calm down when I was wrecking my head over some weird bugs.

As a fan of C#, I'll be entering the world of web development with ASP.NET, but there are so many things to learn before getting started! Javascript, bootstrap, css grid stuff, angular vs react things, docker, microservices, http and REST stuff, accessing some remote thing through ssh. I feel so intimated and don't know where to start!

I rewrote a giant VBA workbook (lots of business formulas, custom pivots of the data) into Java apps/microservices so that new tabs, other reports can be easily added using (JSON) data from the other apps.

In general, I was the only dev in the team that understood that monoliths are hard to change or scale...

So I've a little freelance project, is basically a blog. I've decided to use microservices with angular in the front end and python in the backend.

I've been about 2 weeks copy pasting code in my api because all the modules are pretty simple CRUDs that do the same thing, there is not heavy business logic or anything, just database handling.

I was really tired of copy pasting modules and his test, only changing function names and parameters, today I've this "epifany" about the inheritance and thinked about using it in my service, creating a base class and making all the other classes children of him.

Before the change my project has 220 tests (100% coverage) now I have only 40 tests (the same 100% coverage)

So, the lesson is: don't start throwing code like an idiot and start your project with some good planning

Any devs out there worked building Golang microservices for a production environment?

I don’t have a specific question really. Just wondering who is out there on a similar path!

I’m building using Golang, Google Cloud, Docker, Kunernetes, and Terraform currently on a personal product bound for production!

Microservices in real life:
You have 4 different project opened in IDE simultaneously editing all of them to make something to work.
All projects share same db.
Basically this is monolith but splitter to different git repos.
Communicating one another via http calls or directly altering shared db tables.
Everyone is happy until solution goes to production then :
Solution doesn't scale because db is a bottleneck.
Services can be unavailable for 1-2s so some processes are left in unfinished state forever, because everyone assume 99,9% SLA means it always available and http calls will never fail.
Http calls take time.

Starting my work day:

* fire up the build script wrapper script wrapping the Docker compose scripts, which starts I dunno 20 different microservices, frontend build processes, watchers, blah, blah, blah, chews my laptop's battery like a muthafukka, wait for 15 minutes, for maybe a 40% chance that maybe it'll work, or maybe I'll have to fix some random thing that's wrong out of the 20 million things that could possibly go wrong and then restart... and if I'm lucky at the end of all this, I get to work on, I dunno, adding some field to a modal?

Firing up my weekend side project:

* php -S and immediately start working productively every time

Fuck the "modern web"

Microservices

Lets take an example: Products service & orders service.

When I want to save an order for a user, data saved as
1. UserId, ProductId, Quantity, Date

Or
2. UserId, Name, Email, ProductId, ProductName, Quantity, Date

I'm a bit confused here because if I'm going to fetch that purchase, in example 1, it will return IDs requiring another trip to server to get user & product info

In example two it takes only one trip BUT if any changes is made to either user info or product info it means I'm returning wrong info to the user.

What do we do in this scenario? Excuse my questions first time applying Microservices and been using monolith all my life

A lot of this might be an assumption based on not enough research on both NestJS and TypeScript, so if something here is not well put or incorrect then please feel free to provide the necessary info to correct me since I care far more about getting dat booty than I do being right on the internet :D

Sooo, a year or so ago I got a hold on the Nest JS framework. A TypeScript based stack used to build microservices for node. Sounded good enough in terms of structure, it is based on the same format that Angular uses, so if you use Angular then the module system that the application has will make sense.

I attempted (last night) to play with the framework (which I normally don't since I am not that much of a big fan of frameworks and prefer a library based approach) and found a couple of things that weird me out about their selling points, mainly, how it deals with inversion of control.

My issue: This is dependency injection for people that don't really understand the concept of dependency injection. SOLID principles seem to be thrown out of the window completely due to how coupled with one another items are. Literally, you cannot change one dependency coming from one portion to the other(i.e a service into a controller) without changing all references to it, so if you were using a service specification for a particular database, and change the database, you would have to manually edit that very same service, or define another one....AND change the hardwire of the code from the providers section all the way into the controllers that use it....this was a short example, but you get the gist. This is more of a service locator type of deal than well....actual dependency injection. Oh, and the documentation uses classes rather than interfaces WHICH is where I started noticing that the whole intention of dependency injection was weird. Then I came to realize that TypeScript interfaces are meeheed out during transpilation.

Digging into the documentation I found about custom providers that could somehowemaybekinda work through. But in the end it requires far too much and items that well, they just don't feel as natural as if I was writing this in C# or Java, or PHP (actually where I use it the most)

I still think it is a framework worth learning, but I believe that this might be a bias of mine of deriving from the norm to which I was and have been used to doing the most.

Need some advice here.

So hello everyone! I recently moved abroad for work, for the sake of the experience and the excitement of learning how developers in Latin America tackle specific problems. To my surprise, the dev team is actually composed solely of Europeans and Americans.

I work for a relatively new startup with an ambitious goal. I love the drive everyone has, but my major gripe is with my team lead. He's adverse to any change, and any and all proposals made to improve quality of throughput are shot down in flames. Our stack is a horrendous mess patched together with band-aids, nothing is documented, there are NO unit tests for our backend and the same goes for our frontend. The team has been working on a database/application migration for about a month now, which I find ridiculous because the entire situation could have been avoided by following very rudimentary DevOps practices (which I'm shunned for mentioning). I should also add that for whatever reason containerization and microservices are also taboo, which I find hillarious because of our currently convoluted setup with elastic beanstalk and the the constant complaints between our development environment and production environments differing too much.

I've been tasked with managing a Wordpress site for the past 3 weeks, hardly what I would consider exciting. I've written 6 pages in the past two weeks so our marketing team can move off of squarespace to save some money and allow us more control. Due to the shit show that is our "custom theme" I had to write these pages in a manner that completely disregard existing style rules by disabling them entirely on these pages. Now, ironically they would like to change the blog's base theme but this would invertedly cause other pages created before I arrived to simply not work, which means I would have to rewrite them.

Before I took the role of writing an entire theme from scratch and updating these existing pages to work adequately, I proposed moving to a headless wordpress setup. In which case we could share assets in a much more streamline manner between our application and wordpress site and unify our styles. I was shot down almost immediately. Due to a grave misunderstanding of how wordpress works, no one else on the team seems to understand just how easy it is to fetch data from wordpress's api.

In any event, I also had a tech meeting today with developers from partner companies and realized no one knew what the fuck they were talking about. The greater majority of these self proclaimed senior developers are actually considered junior developers in the United States. I actually recoiled at the thought that I may have made a great mistake leaving the United States to look a great tech gig.

I mean no disrespect to Latin America, or any European countries, I've met some really incredible developers from Russia, the Ukraine, Italy, etc. in the past and I'm certainly not trying to make any blanket statements. I just want to know what everyone thinks, if I should maybe move back to the states and header over to the bay/NY. I'm from the greater Boston area, where some really great stuff is going on but I guess I also wanted a change of scenery.

So this manager told me we need to build accelerator. What's an accelerator. He told that it some how manages Microservices.

Rails, React, React-Native, Docker, Kubernetes, Openstack, Jenkins, AWS, Microservices, Realm, MongoDB, PostgresQL, GraphQL (list goes on...), and I'm not even done yet.

6 months was spent learning all of the above because I found a Rails-only monolith on Heroku unsettling. My first batch of containers was just deployed and I couldn't be happier. Love my job.

We've been working on a big application on-and-off for the last year (whenever we had time.) It was 99% working, and we left it to work on some other apps. We come back to it, only to find that some big features have magically stopped working. We dig into it and find thT some other dev team completely changed the functionality of one of the existing off-application microservices were utilizing without telling us, and then we had to spend days reverse-engineering what they did so we could retrofit our application to communicate with the microservice again.

We were able to get it fixed, but I just know that they're going to change something else in the future without telling us and it's gonna break again. A little interdepartmental communication would be greeeeaaaat!

So a while back I decided to overhaul my entire code base and rewrite everything in one application... yesterday I thought this was bad so have moved back to separate applications, just this time as microservices! Does anyone else do this without ever releasing the initial thing you set out to do?

Slowly adapting Go to some microservices projects I have. Shit is intuitive as fuck and I believe it has to do with what lil knowledge I had of working with C back in uni and by myself. For the web Go fits quite nicely. Really loving my time working with this language.

Now, if i could somehow throw it into the mix at work and build something with it it would be quite fun.

Hmm. I've been wondering how I'll deploy an api based on a microservice style the smartest way... The general plan was to use salt to setup the base server and install dependencies and add the configuration.. Doing updates would be a git pull and pm2 restart api. I would love to know how you deploy your software ?

I work as android dev for the past year and a half, this week in my startup I started doing some backend (it consists of microservices, codebase is written in python. were using rabbitmq for queuing and for http our framework is falcon).

At first I was very adamant to learn new stuff but now that Im getting deeeper into backend I started to really enjoy it!

Its still lots of new information but at the same time it feels soo refreshing to have two experienced mentors who can guide you, since Ive spent last year and half working on android completely by myself and relying only on myself. Also im very lucky that codebase is clean.

nginx microservices training through work?? fuck yea!

Given an opportunity to develop an application for R&D. What do we do as a team? Let build it exactly the same way our current stack is built. (This app won't actually be used for anything useful, just an exercise for a fun R&D task)

It still amazes me with the number of developers that literally have the mindset, let's just do what we know & don't want to learn anything new.

Let's showcase new technologies? No. Let's create a serverless application? No. Let's create some microservices? No. Let's wrap the application in a Docker container so we can easily spin it up? No. Let's have multiple services that sit behind an API gateway? No. Let's for fucks sake at try a different design pattern? Why would we do that? Can we do anything differently? No.

No innovation, nothing - it just blows my mind. Everyone seems to think that the way the stack is built is how every application is. Sorry but a huge monolithic application that can't scale isn't how the other half live...

I don't know why the lack of wanting to try something new bothers be so much, but it does.

Had a real opportunity to showcase some cool tech, design patterns, new services in the cloud. Show not only other devs but upper management that there are alternative ways to develop. It's not like anything that I put together was "new or shiny" - I just wanted to do anything... Anything that isn't how currently do things.

Full disclosure, I'm not a great Dev - I'm pretty dam average but I'm always willing to try new techniques or approaches.

Discovered this weak a breaking flaw in the micro-service pattern.

I don't have enough screens.

how do you develop/transition to microservices when the company does not even have developers for the core systems? all systems are either developed by or bought from software vendors. they just go and decide that they want microservices. SMH!

Is it weird that I hold a high degree of respect for every sector in programming. When we talk about front-end, back-end in websites to the GUI support and logical end in desktop applications to cloud-based microservices, I respect clean, swift, and agile developers who who a structural mindset. For the founding fathers of assembly to high-programming languages like c all the way to high-high level programming languages like C#, JavaScript, Python, I respect them and thank them for their time and dedication in relatively stable libraries. I also thank the creators of OOP and FP as well as the developers that make great use of these paradigms. I come to realization that no one wants to fuck shit up; the great engineers of our past wanted to build some legit, non-trash programming tools, and we can't bash them for that. Respect, courteously critique, and build applications and programming tools to a standard that someone in the future would admire and be grateful for.

Things I want to accomplish in 2023:

- learn rust
- learn a functional programming language (elixir probably)
- finish the O'Reilly book about microservices
- learn and contribute to gnunet
- read at least other 2 books about SE

Regarding the last point, I've always underestimated SE books.

Anyone experience with microservices?

I want to offload CPU intense workloads to another server while I use my main webserver for just simply serving files and I have a couple of questions... Like were to start researching if this idea is even viable

Thanks in advance!

Question.. architecting a large system. I’ve broken it down to microservices for the DB and rest API / gateway

I want there to be some some processes that run continuously not event driven via rest. Say analytics for example what is the best way todo that? Just another service running on on a server? And said service has its own API? That when the other rest APIs are called could then hop and call the new service?

Or say we had a PDF upload via rest should that service then do the parsing before uploading to DB .. or should the rest api that does the uploading then call another rest api to another service dedicated todo the parsing and uploading to the db?

I think the bigger way to explain the question is the encapsulation between DAL.. data access layer which I have existing.. but then there’s the BLL .. buisness logic layer which I don’t know if it should have its own APIs via own microservices running in the background.

I have been struggling with managing and keeping track of config secrets and keys. I know that keeping secrets in code is bad karma, but managing them with environment variables becomes cumbersome with multiple microservices running on multiple servers. To worsen this, add humans and access levels.

Whenever I Google, I feel like I am the only one who has this problem. Do you guys sometimes feel like this?

If you have any solutions, hacks or services that you use, please recommend.

I go to add a method call in a business logic class that's used exclusively in a particular service, and get blocked in the PR by some other guy-

Other Guy: refactor this into the shared framework referenced by all our microservices

Me: it is only and would only be used in this service

OG: what about the other business logic class in this service?

Me: it's not used there, and if it does end up used there then we can refactor it into a class that they both reference then

OG: I need to know when the abstraction of this function will be done. is it going to be delivered next sprint?

Me: YAGNI - better to avoid doing extra work when we don't know if we'll even need it

OG: tbh you can still abstract it with some generics and lambda magic, but im not gonna enforce that

Me: premature abstraction is the root of all evil (tongueout)

OG: not really, its the root of not having a million miles of tech debt in 2 years

I just can't win for losing with the anti-YAGNI yogi.

It's a career suicide wanting to transitioning to desktop developement? I'm tired of fighting with tons of external dependencies (VPN, database, other microservices) just to test a microservice or a piece of front-end, I just want to focus on code.

My job description is software developer but I'm spending more time playing the sysadmin to keep my local developement environment working than what I spend actually coding.

I have nothing to do today. I could go Jack off in the bathroom for 3 hours, then go home and my boss would be proud of my hard work. He told me to leave him alone because he is busy today after I went back 10 time for more tasks. We don't use any issue tracker or anything, and I already commented all the code I have access to(microservices means it is all developed in small stand alone parts and I can only see mine. No repo....). But I get in chewed out if I seem unbusy!!!

To be a Java (or other business popular language) developer
* Java 6, 8 and features up to 14
* SQL + nosql
* Caching
* Logging eg log4j2,
* Searching eg elastic stack
* Reactive
* Framework (at least 1, but hey, knowing 1 is lame..)
* Networking or at least base http knowledge
* Tomcat, jboss or other shit
* Aws, heroku, GCE or other SAAS/paas
* Rest, RPC, soap
* Business Hello World example
* Hexagonal Architecture
* TDD
* Ddd
* Cqrs
* 12 app factor
* Solid
* Patterns
* docket
* Kubernetes
* Microservices
* Security, oauth2
* concurrency
* AMPQ
* Cloud
* Eureka or consul as service Discovery
* Config server
* Hazel cast
*
*
* Endless story ...

Then we can start hello word app

I had a pretty good year! I've gone from being a totally unknown passionate web dev to a respected full stack dev. This will be a bit lengthy rant...
Best:
- Got my first full time employment dev role at a company after being self-taught for 8+ years at the start of the year. Finally got someone to take the risk of hiring someone who's "untested" and only done small and odd jobs professionally. This kickstarted my career, super grateful for that!
- Started my own programming consulting company.
- Gained enough confidence to apply to other jobs, snatched a few consulting jobs, nailed the interviews even though I never practiced any leet code.
- Currently work as a 99% remote dev (only meet up in person during the initialization of some projects.) I never thought working remotely could actually work this well. I am able to stay productive and actually focus on the work instead of living up to the 9-5 standard. If I want to go for a walk to think I can do that, I can be as social and asocial as I want. I like to sleep in and work during the night with a cup of tea in the dark and it's not an issue! I really like the freedom and I feel like I've never been more productive.
- Ended up with very happy customers and now got a steady amount of jobs rolling in and contracts are being extended.
- I learned a lot, specialized in graph databases, no more db modelling hell. Loving it!
- Got a job where I can use my favorite tools and actually create something from scratch which includes a lot of different fields. I am really happy I can use all my skills and learn new things along the way, like data analysis, databricks, hadoop, data ingesting, centralised auth like promerium and centralised logging.
- I also learned how important softskills are, I've learned to understand my clients needs and how to both communicate both as a developer and an entrepeneur.
Worst:
- First job had a manager which just gave me the specifications solo project and didn't check in or meet me for 8 weeks with vague specifications. Turns out the manager was super biased on how to write code and wanted to micromanage every aspect while still being totally absent. They got mad that I had used AJAX for requests as that was a "waste of time".
- I learned the harsh reality of working as a contractor in the US from a foreign country. Worked on an "indefinite" contract, suddenly got a 2 day notification to sum up my work (not related to my performance) after being there for 7+ months.
- I really don't like the current industry standard when it comes to developing websites (I mostly work in node.js), I like working with static websites (with static website generators like what the Svelte.js driver) and use a REST API for dynamic content. When working on the backend there's a library for everything and I've wasted so many hours this year to fix bugs and create workarounds related to dependencies. You need to dive into a rabbit hole for every tool and do something which may work or break something later. I've had so many issues with CICD and deployment to the cloud. There's a library for everything but there's so many that it's impossible to learn about the edge cases of everything. Doesn't help that everything is abstracted away, which works 90% of the time but I use 15 times the time to debug things when a bug appears. I work against a black box which may or may not have an up to date documentation and it's so complex that it will require you to yell incantations from the F#$K
era and sacrifice a goat for it to work properly.
- Learned that a lot of companies call their complex services "microservices". Ah yes, the microservice with 20 endpoints which all do completely unrelated tasks?

We're doing single login with Azure AD for a Java-based site. We need to also sync the user changes with a microservice.

Now, here comes the fun part: Microsoft is working on a new API which looks promising, which they recommend to use as they've migrated their resources there. But this new API has SDK for a ton of languages but Java, so that's a no-no. On the other side, the js sdk for the old API is borderline unusable and has no deltas (which we need to sync users), although the new one is pretty good.

As a cherry on the cake, applications created with the old API are not transferrable to the new one, but it is otherwise. This is detailed in a very small section of their labrythinc docs and I'm really hoping that this is true or we're thoroughly screwed.

Alas, Microsoft, you've disappointed me again!

Microservices... turning simple stories into mindfucks since.... ah who cares ..... fml

man, this nginx micro-services stuff is unreal - take your monolithic OOP application and split it across your environment and let them talk REST to each other. so sweet!

Hey devRant!

University student here. I’m trying to learn how to build scalable applications. I figured what better way to learn, than to ask this community!

So, some questions:
1. What is a good stack for scalability
2. Regarding microservices, when and where should you use node, .net, and go
3. I hear much talk about docker and kubernetes... how would you use these concerning microservices

Thanks!

What's the difference between Spring Cloud and Boot? And what's a good book to learn either?

And I guess Spring as well. Is that a pre-req? I'm not familiar with much other than Bean and Context and not sure how AutoWired exactly works...

One project I have is to build an REST service but with subservices, and their replicas, handling different paths and on Openshift.

So these sub services need to be independently started but discoverable by the routing app(s).

Not sure how many layers but basically when a call hits the Router, depending on the path in the URL it sends the request to the appropriate subservices

It seems which the crazy enterprise microservice project which I'm doing (an awful distributed monolith splitted in 10+ microservices, hard to test and requiring continued context switching and running on an unreliable platform) has finally won over my brain.
It's so boring and frustrating to work with which I lost all my ability to focus, I used to be able to program well even under significant distress but more than two years of continued boredom, repetitive tasks and frustrations destroyed my motivation and with that my ability of focusing died. It doesn't matter if I'm at home or in the office, my brain is like a car stuck in neutral gear and I struggle to focus in every task.

!rant

Just learned how to use Spring + Eureka + Feign + Ribbon to easily discover microservices as they're deployed, do basic load balancing, easily hitting endpoints on other micro services, etc.

Mind = blown 🤓

Folks are bragging about having 99 microservices. I don't know for what joy folks create that much microservices. They may have their own reason. I'm trying to understand what is the workflow for small companies with few microservices. Could anyone shed some light? I'm thinking of building orchestrator where I don't have fancy features like k8s and get the basic job done. Focused more on simplicity and UX.

Can someone share a roadmap to learn Microservices Architecture in Java?

Time for an exam about Cloud computing and deploying Microservices to the cloud using kubernetes, followed by another exam about Usage of scientific C libraries. This feels both so disconnected for being part of the same degree.

This headhunter even took the time to bold out the hipster verbs like: blockchain, microservices, angular, react and vue keywords and hashtags ...

K thx bye

*BLOCKED*

Anyone have books or blogs about microservices and APIs they like?

I spent so much time focusing on front end frameworks and technologies and now I'm having to teach myself RESTful API structures and micro service stuff. I should have spent more time on this earlier on...

A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.

So my company is starting our microservices journey (we have a 359 retail websites at this moment)

First question was: What to build first?

The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.

We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.

By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.

Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.

Next step: Choosing a datastore

The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.

Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.

We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.

Even bigger challenge? Which programming language will we use

The team responsible for developing this first microservice consists out of a group web developers. So when looking for a programming language for the microservice, we went searching for a language close to their hearts and expertise. At that time a typical web developer at least had knowledge of PHP and Javascript.

What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:

- Execute a HTTP call to fetch some JSON

- Transform JSON to a desired output

- Respond with the transformed JSON

Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.

Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.

To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.

The leap to start programming Node.js is relatively small since it basically is Javascript. A language that is familiar for the developers around that time. While Node.js is displaying some new concepts it is relatively easy for a developer to start using it.

The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.

Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.

Many more headaches to come later this year ;)

In this new World of Microservices Architecture, I fail to understand the monolithic application. My context being for interviews. They keep asking about the old ways. What patterns were used and security situation. How do you tackle that when I did not get a chance to work on old monoliths. But

Today we finally launched Keycloak to secure our spring cloud microservice architecture!

Great feeling after 4 month of tailoring open source software, bug fixes and so much pain 😄

In the year 2015 I graduated from a reputated university. Though I had a couple of offers from my campus Placements, I did not willing accepted those offer and tried updating my CV in job portals.
On the day June 25th 2015, I still remember I recieved a invitation to attend the interview with one of the reputated company and I was like very much excited to attend this interview.

Interview process,
1) I had coding round which lasted for an hour and half and the best part is I scored max marks 😉
2) next round was problem solving or algorithm round it was quite difficult, but somehow I managed to clear that too.
3) final round was managerial round which was very much tougher than these two, My manager was real technical guy who knew most difficult industrial problems. In fact I should thanks him because he thought me how to organise code while development and also he thought me corporate ethics as I was a fresher when I joined there.
4) so I cleared all the rounds and joined the company around 10 days after 25th.
5) my journey in this organisation was very good. I had learnt the tech stack and there I started working as a microservices developer.
Thanks to my previous organisation.

when your microservices go macro.....

Our lead dev has convinced the board to move the new software suite forward into .Net Core 3. Much of his reasoning is sound, a mainstay of which is the cost and ease of hiring developers to actually make and maintain it.

My own roadmap with the company focuses around one of these products, so I am to become the core developer and maintainer. Given thats the case, given that my primary skill is with Javascript/Node and given that we have deadlines, I am going to make the case today that this product might be better built in Node.

We are going for a microservices architecture. Combined with Typescript for type safety as the code base gets bigger, I am not sure I can think of many real advantages to choosing .NET instead. It will benefit from its async I/O later too, as the plan is to build in API driven dynamic UI down the road.

He is a fierce man, and I am the junior. Wish me luck.

Then you start in a new job.. wow big scenarios, complex, hundreds of microservices, large architecture, tons of trainings... and you have a task to check one thing... and you ask, please i need the documentation about this feature. “We don’t have any document. You can track it manually vis debug”

Now I have 7 instances of Visual Studio attached with a lot of services with tons of breaking points looking where the breakpoint will hit
Well done,🤙🏻

The big enterprise in which I work wants to mandate which we have to write a microservice for each individual HTTP endpoint, since we cannot even have an artifactory for code sharing the code duplication is going off the charts and having these microservices sharing a single DB we are creating a big and messy distributed monolith.

"Microservices" implemented on a PHP symfony/doctrine/rabbitMQ stack, whereby the app was daemonized. Lots of fun.

The platform team who provides all other teams with common framework emails everybody we need to upgrade the framework to new version. Let’s say version 1.a.0. They say it brings crucial security features and all pipelines using old versions would be blocked. My colleague created a story to upgrade all of our 10 microservices. When I got to it in a couple of days for some fucking reason they already rolled out 1.a.1 and didn’t inform anybody, the pipelines just logged warning u need to use 1.a.1. Alright, I did the upgrade to 1.a.1 and merged ducking everything in 10 fucking microservices. In a couple of days at morning they roll our 1.a.2 and require everybody to upgrade ducking degenerates as they found a high severity bug. I wanted to start again but was lazy and did nothing all day to learn that at 6pm the fuckers roll out 1.a.3!!! And again require everyone to upgrade!1!1!1eleven
Ten fuxkibg microservices. Goddamit write some unit tests, do friends&family, do fucking tests on small group of your inner clients before rolling out this shit that everybody must to use.
Spat at the display

How to prepare for Microservices Spring Boot interview?

Microservices -

But dude it doesn't fall in my service's domain, you should be taking care of this.

What makes you think it lies under mine?

"It's just as easy to create a small REST microservice as there is for a small one-off script, so let's follow the design pattern of creating a REST service first."

I don't think my manager understands how different in complexity these two things are.

Remind me again why we have to use/support a weird entity creating framework across all microservices? So that every entity is consistent? (Who cares? Microservices shouldn't) Because hibernate is hard? (It isn't, and it's better documented than this, which needs hibernate anyway).

I'm just building a fragile distributed monolith.

Never work on a feature which is too huge so it needs to be divided among multiple developers. Reason because there are high chances that one of the devs will do one or more of these:
- Follow his/her own coding style rather than what the system already follows.
- Write generic flows based on his/her part alone making it super difficult for rest to reuse.

Didn't know it feels so great to take the 4:30pm shuttle back home. I played with my 4 year old, had tea with my wife, tinkered around my personal project, watched a YouTube video on microservices, and to top it all dined together. If only I could do this everyday.

Hi,

Can you provide good resource for microservices with yii2?

Are those related? Cause a client asked about this combination and as far as I could find it seems that they aren't.

A mix of both python 2 and python 3. 4 entry points (although, this was done for the sake of microservices).

All in 1 big monorepo. Hosting a site in mostly static form (i.e each page had it's own index.html with completely different headers and footers, no templates).

Is it actually required to write unit tests in microservices?
every time i write them it feels like im just redundantly copying a method...
Dont get me wrong, im not against testing, I am using test environments, integration tests and mocks, but unit test seem kinda redundant to me.

Do you ever feel your job is too demanding compared to other software engineering jobs?

I've worked in two companies for now.
First company, Kotlin microservices and we had QAs, didn't have to write a lot of tech specs and no post mortem or on call at all (not yet atleast), it was just talk to PO, he tells the business requirement, we work together to make tickets, no legacy code so was easy to know what to do for tech, no monolith to handle or anything, much easier, just code and meetings.

Current job is meetings with PO telling you what he wants, have to write a full on tech spec and also know business requirements and product knowledge as the current PO doesn't know anything about how the products work, writing huge tech specs, communicating on requests sent my clients on slack, pretty much always firefighting, the system is so fragile and legacy, coding is actually less its mostly spending hours finding out how this shittt legacy flows work (no docs) , PO pretty much does fuck all, just wants meetings and wants us to do very very stupid tedious low impacts projects. This bundled with oncall and onpoint and the absolute sheer amount of incidents our team is involved in (on average we have 4 a week LOL, varying size but they're all very annoying) and the overtime oncall benefit is so bad too, if you do get paged out of hours, you just get that hour back during work hours. In other companies like friends, you get paid for the whole time you're oncall, whether you get paged or not. I can't go out anywhere on weekends or anywhere at all during on call in case I get paged, which happens a lot. Its a cluster of a mess. This bundled with manager stoll not wanting to promote me to IC3 despite all I've done so far.

My question is, is this more normal than I think it is? Is this just how crap our career can be? Mind you I'm in the UK so not getting those mind boggling US wages sadly either. Have US colleagues in same team doing same job but obviously getting more

Does Really Nodejs - js environment is the best environment in the world ? i mean why people create their RESTful API in js ? from singular to microservices ? does it really that scalable ?

do i have any alternative ? i can't stand anymore change working with js anymode :(

As if dealing with an unstable infrastructure and being unable to properly test microservices I work on Isn't enraging enough now developers at my workplace have to double as Ops too and have to configure themselves the K8s pods and containers in which our code runs. That would be ok for me if it isn't for the fact which we should do that trough company's shitty documented and totally leaky abstractions.

I'm afraid of trying micro-services for the second time, spent my evening couping playing Far Cry 5 instead :/

(this time with go kit toolkit).

Anyone else microservices are repackigng of basic software enginering?

How do you keep shared libraries used by multiple microservices in sync?

For example, a model class in a shared lib used by some of your microservices. If a new field is added, how would you quickly identify which microservices need to be updated, redeployed? And do it quickly.

Or say the model library has many classes, used by different services. 1 class changed, and only 2/10 services reference it. Do you target only three 2 or so of them? Or would those be bad design?

I've been working for over a year now in this remote job as a sysadmin for a local client. I personally find this job quite intimidating at first with all of the infrastructure and all of its many microservices running in high availability set up. I enjoyed learning everything about them and why it's been set up this way, which gives me ideas if I were to build my own app (not competing with my current employer, of course).

But now I don't feel comfortable managing this beast in its many environments.

From time to time, I would hear from my old colleagues at my old sucky company for help in their work and that they know I'm an expert in. I help and it makes me feel good.

Now I'm at a career dilemma. I don't want to lose my current job because I feel "uncomfortable" with managing and administrating the tech holding the whole infrastructure. And I don't wanna go back to my old job with the sucky pay and the feel of being unchallenged. And if I try to find another job, I might be as lucky as I do now, especially good difficult it is for me to find a remote job to begin with.

Objectively, I just need to clear off my debts (at this rate, in 4 years), and have a side income to support my family. But I don't think I can follow through on that plan. Should I look for a new job or do better with the current job that I have now?

A module for molecules, which take an OPEN API definition and creates a restful API and graph definitions.

So all the proxy database stuff on a rest API can be done easily inside a microservices architecture.

Any suggestions for good reading regarding the boundaries of Microservices? By this I mean a domain driven design approach.

I have a pretty good idea of what I “think” is right for my project. But something is telling me to challenge my idea.

For a little bit of background... I am using separate DBs for each Microservices, and building APIs to access the information across the system.

There are so many things I don't understand the point of in technology

Like microservices

There are other things I just have difficulty comprehending like natural language models

Let's focus on that one.

From the explanation I saw it takes presence of words in typical language

So what the input neurons representing every word in the English dictionary?

The message gets changed to this and the output neurons are the existence of these words likely as a response to the input and BAM chatgpt converts output weighta somehow to full sentences and paragraphs?

I feel I'm missing some important point

Is there well documented code anywhere?

No unit tests, on about 10 deployed Microservices. Next week is test week.

Nothing like constantly having to spend 3-5 days of spin up on trying to help another team with their microservices because they have such a severe lack of documentation that I can't just follow a readme to get their projects running. Instead, I have to bug one of their developers to help me get it up and running (because they use non-standard project setups and dependency management), delaying things even more. No matter how much I scream that we need documentation no one makes it a priority.
Did I mention these are microservices written in Golang and I'm a front end developer? And I'm being made to work on back end tasks because we have a crazy high attrition rate and they won't back fill the back end positions.

I was looking for a book on Microservices Architecture. There are several books, but I need one which explains all the patterns and related styles on design. The reason being is, I'm convinced about Microservices, but I need to convince my fellow teams and managers.

I NEED HELP with Kafka

I'm working a thesis. I developed 4 different microservices (REST APIs). I would like to use Kafka to support large number of users. I may also place the microservices behind a HAPI Proxy. How can I use Kafka to stream requests and respond accordingly. I'm using Node.js. I think I haven't grasped Kafka. My Prof, suggested I try it to act as a broker but I'm blank right now. How do I tell Kafka I want it do a POST or GET etc?

Does anybody know, how resilience could be achieved if any of your microservices is down. Please suggest me if any. I had one approach in mind but that doesn't seem to be efficient.

I just thought of an elegant solution to a problem in prod. Basically need to run 2 different versions of a app.

Just deploy it to uat and point it to prod db for the data.

I guess if we were following microservices architecture though we could deploy both versions to prod but we don't....

All the microservices are planning to communicate via kafka. And they are planning to put a REST API between kafka and the service. So all services hit the REST API with the events and the REST API send events to kafka.

I don't see any benefit of having a REST API between the service and kafka. What are the opinions in the wild?

Is any other microservices framework out there rather then gRPC?

Question directed to devs who know a bit about setting up middle sized architecture.

Prestory: Joined into development of a middle sized online game. Figured they created a monolith over the last 6 years up to a point where nothing works properly and nothing can be changed without wrecking the whole system. Figured a monolithic approach isn't such a great idea.

Current Situation: In a different, same scale online game development team, game itself working but team is struggling with architecture.
My job is to come up with an approach on how to set up masterserver/matchmaking/database etc. Reading through various articles about common principles (SOLID etc.), i figured that a microservice+event-/servicebus architecture may work for that kind of project.

The idea would be to have a global interface in which microservices can be hooked. So a client registers to a client handler on startup, then starts to queue for a game, the client handler throws an event on the bus to register the user to matchmaking. The matchmaker happens to listen to those events (Observer Pattern) and adds him to matchmaking, when a match is found it throws an event on the bus to connect the user to the server, etc. One can easily imagine a banhandler throwing in a veto to cancel such an action, metrics and logging is fairly simple to add (just another service listening to all events), additionally Continuous Delivery, FRP and such are also beneficial advantages and it is said to scale well.

The question is, would you do the same, is there maybe something i might be overlooking? Do you have better ideas?
Keep in mind that we are not too experienced and are bound to different languages (python, C++ and java mostly) and are a small (4 Devs) Team with different strengths.

Thank you for your feedback and criticism!

Go or Kotlin for microservices?

Our company has the opportunity to start moving towards a more microservices architecture approach.

There is so much technical debt that needs to be paid back, this opportunity is a godsend!

Now, of course, the whole "programming language debate" comes into play at this point.

To provide some context, we've reached the point where we need to be able to scale, and at the same time where speed and performance are also important. I would argue that scale is of more importance at this stage.

Our "dev manager" (who is really only in that position since he's the oldest, like scribbling on a notepad and the sound of his own voice) wants to use Rust, as this is a peformant language. He wants to write the service once and forget about it. (Not sure that's how programming works, but anyhoo). He's also inclined to want to prematurely optimize solutions before they're even in production.

I want to use Typescript/NodeJS as I, along with most on the team are familiar with it, to the point that we use it on a daily basis in production. Now I'm not oblivious to the fact that Rust is superior to Typescript/NodeJS, but the latter does at least scale well. Also, our team is small - like 5 people small - so we're limited in that aspect as well.

I'm with Kent Beck on this one...
1. Make it work
2. Make it right
3. Make it fast

We're currently only at step 1, moving onto step 2 now!

Design Decision:
We have an API and a lot of microservices based on that API. Additionally we have a store of protobuf-templates (files to automate serializing certain events etc).
Currently for each service we have the API with general stuff (connection stuff etc) and then copy the 5 or 6 proto-files we need for that service, they update sometimes, so does the API, for each service, two things that need to stay updated. Which option would seem more logical to you?

a) Integrate all proto files into the API. The services then only need to update the API but they also have access to many proto files they don't need for that service (which are required for other services however)

or

b) Keep them seperated and keep manually updating the proto-files for affected services

Disclaimer: our proto files are always backwards compatible by design, both the API and protofiles change fairly frequently.

Ty

Backend wise

After a year and a half of working with what i love (nodejs microservices and bit of python) I have to update my php skills and refresh my memory with latest Laravel 😕 (I used it as an authentication/authorisation and REST backend for a react native app early 2016 and did not touch it since)

Passive Job hunting sux and yes PHP ain't my thing anymore 😔 i mean i have next to 6-8 years exp in it but given the choice... 😒

I used to love it (so many good memory with cakephp 😌🙄it teached me a lot early in my carrer) before I discover functional programming paradigm and got deep understanding of JS

Projecting and developing microservices architectures at big companies. Also I hope I'll be contributing the kernel a day