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)

"Coding is solving puzzles".

I think everyone has heard that platitude. But it's not exactly right.

So I grew up in a very poor environment, a moldy building full of jobless addicts.

And in my town there was this shop where super poor parents could take their kids to borrow free toys and stuff.

So as a kid I remember being frustrated by these second hand jigsaw puzzles, because there were always a few pieces which had been teared up or chewed on, or were even completely missing.

That is what development is.

You pull in this seemingly awesome composer package, and that one super useful method is declared private, so you need to fork the whole thing.

Your coworker has built this great microservice in python, but instead of returning 404 not found, it returns 200 with json key/value saying "error": "not found".

There's a shitload of nicely designed templates for the company website, but half of them have container divs inside the components, the other half expect to be wrapped in container divs when included.

You're solving puzzles, but your peers are all brainless jigsaw-piece-chewers. They tried to mend a problem, but half way through got distracted, hungry and angry, started drooling over the task and used a hammer to fit in the remaining stuff.

I think the weekly rants just exist because @dfox & @trogus got banned from stackoverflow and they still have questions.

When it comes to learning cutting edge tech... Go build already!

I found Rust intimidating.

I read the first few pages of the official book, got bored, gave up.

Few months later, decided to write a "simple" tool for generating pleasing Jetbrains IDE color schemes using Rust. I half-finished it by continuously looking up stuff, then got stuck at some ungoogleable compiler error.

Few months later I needed to build a microservice for work, and against better judgement gave Rust a try in the weekend. Ended up building an unrelated library instead, uploaded my first package to crates.io.

Got some people screaming at me that my Rust code sucked. Screamed back at them. After lots of screaming, I got some helpful PRs.

Eventually ended up building many services for work in Rust after all. With those services performing well under high load and having very few bugs, coworkers got interested. Started hiring Rust engineers, and educating interested PHP/JS devs.

Now I professionally write Rust code almost full-time.

Moral of the story:

Fuck books, use them for reference. Fuck Udemy (etc), unless you just want to 2x through it while pooping.

Learning is something you do by building a project, failing, building something else, falling again, building some more, sharing what you've made, fighting about what you've built with some entitled toxic nerds, abandoning half your projects and starting twelve new ones.

Reading code is better than reading documentation.

Listening to users of your library/product teaches you more than listening to keynote speakers at conferences.

Don't worry about failures, you don't need to deliver a working product for it to be a valuable experience.

Oh, and trying to teach OTHERS is an excellent method to discover gaps in your knowledge.

Just get your fucking hands dirty!

To be a good developer, you must thrive in chaos, and have an insatiable desire to turn it into order.

All user input, both work tasks and actual application input, is pure fucking chaos.

The only way to turn that input into anything usable, is to interpret, structure and categorize it, to describe the rules for transformation as adequately as you can.

Sometimes companies create semi-helpful roles to assist you with this process. Often, these people are so unaware of the delicacy of the existing chaos, that any decision they make just ripples out in waves leaving nearly irreparable confusion and destruction in its path.

So applications themselves also slowly wear down into chaos under pressure of chaotic steak-holders which never seem to be able to choose between peppercorn or bernaise sauce for their steaks.

Features are added, data is migrated between formats, rules become unclear. Is ketchup even fucking valid, as a steak sauce?

The only way to preserve an application long term, is refactoring chaos into order.

But... the ocean of chaos will never end.

You must learn to swim in it.

All you can hope to do is create little pools of clarity where new creative ideas can freely spawn.

Ideas which will no doubt end up polluting their own environment, but that's a problem for tomorrow.

So you must learn to deal with the infinite stream of perplexed reactions from those who can't attach screenshots to issue reports.

You must deflect dragging conversations from those who never quite manage to translate gut feeling into rational sentences.

You must learn to deal with the fact that in reality there are no true microservice backends. There are no clean React frontends. There are no normalized databases. Full test coverage, well-executed retrospectives, finished sprints -- they are all as real as spherical cows in a vacuum.

There is no such thing as clean code.

There is only "relatively cleaner code", and even then there are arguments as to why it would be "subjectively relatively cleaner code".

Every repository, every product, every team and every company is an amalgamation of half-implemented ideals, well-intended tug of war games, and brilliantly shattered dreams.

You will encounter fragmented shards of perfect APIs, miles of tangled barbed documentation, beheaded validator classes, bloody mangled corpses of analytical dashboards, crumbled concrete databases.

You must be able to breathe in those thick toxic clouds of rotting technical and procedural debt, look at your reflection in the locker room mirror while you struggle yourself into a hazmat suit, and think:

"Fuck yes, I was born for this job".

My team was sharing an API key to our company's microservice containing all our customer data.

I say "was" because one team member accidentally published the key online so the security team disabled our key and won't give us a new one.

I don't know whether to laugh or cry

Still trying to get good.

The requirements are forever shifting, and so do the applied paradigms.

I think the first layer is learning about each paradigm.

You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.

Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.

You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".

Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.

Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?

All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.

I think I'm somewhere between 2 and 3.

I think I have most of the important knowledge about a wide array of languages, technologies and architectures.

I think I know how to come to a conclusion about what to use in which scenario -- most of the time.

But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.

The newest *DD development trend: Panic Driven Development.

When your hexagonal domain driven serverless microservice architecture explodes in production and you don't know which one of the 50k components is failing.

C=consultant
M=Me
D=my Dumb boss

M: so how are you guys planning to implement the block all accounts feature?
C: oh it should be easy! We will just loop over every account and lock it!
M: what about implementing a flag that just blocks anyone from accessing the site till further notice?
C: what? I’m sure it’ll work. Just need a list of all accounts, we don’t need anything fancy!
M: what happens when we want to revert back to the pre-block state?
C: oh, so we will just unblock everybody
M: even people who were previously blocked for good reasons?
C: i guess so, unless you think otherwise
M: we r….
D: listen! We just need to be able to block all accounts, who cares about this details! So long as we block all accounts! We need this nuclear option in case something bad happens…
M: but what about when that bad thing passes and…
D: when it passes it passes who cares!

Arghhh so much rage here… like first at the stupid engineering design of looping over all of the accounts instead of using a simple flag. Like 1 http call (from one microservice to another) is a lot better than O(n)… not to mention, we won’t have to deal with failures and retries.

And second for my boss being a dumbass… ok you deal with being to afraid to unblock people after we used this “genius nuclear option”!

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!

"Your XML is malformed by these strange tags CDATA. I've cleaned it up ;)"

Fuckity Fuck my boy, now the whole website is down. All hail the magic push to prod button.

(there were snippets of user provided HTML that was passed over XML by a microservice)

A Microservice Discord bot with a conversational AI using Tensorflow

PORTFOLIO INFLATION

when every junior is writing algorithms, the next step up, the only way to keep up is writing apps. When every junior is writing apps, the next leg up is writing an entire SN.

Eventually junior full stack devs are writing microservice streaming cloud backend content delivery optimized social networks wrapped in virtualization with load balancing, proper CI, public accessible analytics apis, written in custom webaseembly compiled scripting backend utilizing both the latest graphql and every single feature of postgres, while also being a web site builder, an in browser app, mobile optimized, designed to transmogrify your asset pipelines linearflow functional-oriented modular rust cratified turbencabulator while cooking your turducken with CPU cycles, diffusing your gpt, and finetunning your llama 69 trillion parameter AI model to jerk you off all at the same time.

And then the title "wizard" becomes a reality as the void of meaning in our lives occupied by the anxiety of trying to reduce the fear of rejection in job hunting, is subsumed by the brief accidental glance into the cthulian madness-inducing yawning abyss of the future which is all the rest of our lives we have to endure existing for until at last sweet sweet death consumes us and we go to annihilation never having to configure one more framework or devops deploy of another virtual environment.

And it dawns on us that we no longer develop or write code at all. No, everything has become a "service" in this new hellscape future. We slowly come to the realization that every job is really just Costco greeter, or eventually going to be reduced to something equivalent, all human creativity, free will and emotions now taken care of by the automation while we manage the human aspects, like sardines pushing against one another not realizing their doom has been sealed along with the airless can they have been packed into, to be suffocated by circumstance and a system designed to reduce everything to a competition of metrics designed by the devil, if the metrics were misery", and "torture", while we ourselves are driven by this ratfuck wheel to turn endlessly toward social cannibalism, like rats eating their babies, but for the amusement of wallstreet corporate welfare whores who couldnt turn a dime if it wasnt already stolen.

And on our gravestones, those immortal words are carved, by the last person who gave up the ghost, the last whose soul wasnt yey shovelled onto the coal fires driving the content machine consuming the world:

Welcome to costco. I love you.

I shit you not. This this a job qualifications qualifications entry level on LinkedIn.

7+ years working as part of a development team and with the following technologies:
Node.js Typescript and Java-based, microservice-driven applications using Spring Boot or similar framework
RESTful API design / microservice architectures
MongoDB or any other NoSQL DB
Message queues e.g. RabbitMQ, Kafka etc.
Modern MV*(MVC, MVVM, etc..) frameworks e.g. React, Angular, Vue etc.
JavaScript and design patterns, CSS and HTML
Modern CSS and view libraries e.g. RxJS, Angular Material, Typescript, JS ES6 etc.
Unit and UI testing using third party tools e.g. Jest, Cucumber, Groovy & Spock, etc.
Bachelor's degree in computer science or related field

So... Manager pulls us in. Meeting in 10 minutes guys. I know it's unplanned, but it's important.

Not only is it the 10th time he's interrupted my workflow, but it's almost time to go home. And I was getting some important shit done.

Anyways, come the meeting: we are going to abandon all the work we've done on our microservice platform (2yrs+ in the making) and make it a monolith. Oh, and we have to do it in 4 weeks, because a client is asking for it. Oh, and you'll probably have to do overtime.

🤦‍♂️ FML

I miss old times rants...So i guess, here it goes mine:

Tomorrow is the day of the first demo to our client of a "forward-looking project" which is totally fucked up, because our "Technical Quality Assurance" - basically a developer from the '90-s, who gained the position by "he is a good guy from my last company where we worked together on sum old legacy project...".
He fucked up our marvellous, loose coupling, publish/subscribe microservice architecture, which was meant to replace an old, un-maintainable enormous monolitch app. Basically we have to replace some old-ass db stored functions.
Everyone was on our side, even the sysadmins were on our side, and he just walked in the conversation, and said: No, i don't like it, 'cause it's not clear how it would even work... Make it an RPC without loose coupling with the good-old common lib pattern, which made it now (it's the 4th 2 week/sprint, and it is a dependency hell). I could go on day and night about his "awesome ideas", and all the lovely e-mails and pull request comments... But back to business

So tomorrow is the demo. The client side project manager accidentally invited EVERYONE to this, even fucking CIO, legal department, all the designers... so yeah... pretty nice couple of swallowed company...

Today was a day, when my lead colleague just simply stayed home, to be more productive, our companys project manager had to work on other prjects, and can't help, and all the 3 other prject members were thinking it is important to interrupt me frequently...

I have to install our projects which is not even had a heart beat... not even on developer machines. Ok it is not a reeeeaaally big thing, but it is 6 MS from which 2 not even building because of tight coupling fucktard bitch..., But ok, i mean, i do my best, and make it work for the first time ever... I worked like 10 ours, just on the first fucking app to build, and deploy, run on the server, connect to db and rabbit mq... 10 FUCKING HOURS!!! (sorry, i mean) and it all was about 1, i mean ONE FUCKING LINE!

Let me explain: spring boot amqp with SSL was never tested before this time. I searched everything i could tought about, what could cause "Connection reset"... Yeah... not so helpful error message... I even have to "hack" into the demo server to test the keystore-truststore at localhost... and all the fucking configs, user names, urls, everything was correct... But one fucking line was missing...
EXCEPT ONE FUCKING LINE:
spring.rabbitmq.ssl.enabled=false # Whether to enable SSL support.

This little bitch took me 6 hours to figure out...so please guys, learn from my fault and check the spring boot appendix for default application properties, if everything is correct, but it is not working...

And of course, if you want SSL then ENABLE it...
spring.rabbitmq.ssl.enabled=true

BTW i really miss those old rants from angry devs, and i hope someone will smile on my fucking torture

I miss when my job was just about coding, I could spend entire workdays writing C# or TypeScript while listening rock or metal with few meetings in between, being very passionate in programming and computers sometimes I found was I doing so engaging which I spent more than my 8 hours workday on company's code base trying to improve it and my older coworkers were very happy with my code.

Then a "promotion" happened, I went to work directly with a client, a huge enterprise which is working on renovating his internal software and here the fun stopped. Long useless meetings are a regular occurrence, there are absurdly long procedures to do everything (for example since CI/CD is leaky we have to do dozens of workaround to get a microservice deployed) and having very little written documentation this gives an huge advantage to people which actually enjoy to spend their entire workdays on a MS Teams call over "lone programmers" like me which actually feel significant fatigue in doing that (alone sometimes I was able to log 12+ hours of programming daily between work and personal projects while after 3 hours of PP I feel drained) since the information passes in meetings/pair programming and I dread both.

I feel which my passion is still there, I still enjoy coding, tinkering with Linux and BSD, broadening my knowledge with technical books and having passionate conversation about tech but I dread my job, sometimes I try to look at it under a more optimistic eyes but most of the times I just end disappointed.

Fucking incompetence

Senior level developer with 15 years of software development experience ...

ends up writing brute force search on a sorted data - when questioned he's like yeah well dataset is not that large so performance degradation will be marginal

He literally evades any particularly toil heavy task like fixing the unit test cases , or managing the builder node versions to latest ( python 2 to 3 ) because it's beneath him and would rather work on something flashy like microservice microfrontend etc. -- which he cannot implement anyway

Or will pick up something very straightforward like adding a if condition to a particular method just to stay relevant

And the management doesn't really care who does what so he ends up getting away with this

The junior guys end up taking up the butt load of crappy tasks which are beneath the senior guy

And sometimes those tasks are not really junioresque - so we end up missing deadlines and getting questioned as to why we are are not able to deliver.

Fuck this shit ... My cortisol shoots up whenever I think of him

"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." -Doug McIlroy

In today's context we can draw parallels with the microservice approach towards building software.

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

Finished writing a microservice in NodeJS. Wrote tests, had clever optimisations, did profiling, the works. Lead dev says to me on a Friday evening to port my code to Java in 2 days. (Reason: to standardize everything) #FML

Our team - if ever existed - is falling apart. Pressure raising. Release deadline probably failing. No release ready for Big Sur.

Almost seemed we were getting somewhere: More focus on code quality, unit tests, proper design, smaller classes. But somehow we now ended up in "microservice" hell; a gazillion classes, mostly tested in isolation, but together they just fail to do their job. A cheap and dirty proof of concept from March is still more capable than this pile. I really start to doubt all that "Clean code", TDD, Agility rhetorics. What does it help you, if nobody cares for the end result? It's like a month I try to hammer down that message: we have to have testable artifacts, we have to ensure code signing works, our artifact is packaged and installable, we have to give QA something they can test - but time just passes and this piece of shit software is still being killed or does nothing.

Now my knee is broken and can do no sports and are tied to my chair even more. To top it all my coffee machine broke and my internet connection was abysmal this week. Not the usual small disconnects, after which it would recover, but more annoying and enduring: often being throttled to 1.7 MB/s (ranking my connection in the slowest 7% even in Germany). My RDP sessions had compression artifacts all over the screen and a mouse click would only take effect 5 sec later.

But my Esspresso machine was just repaired. Not all hope is lost.

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 ^^

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?

When a microservice you created does not perform on prod like it performed on the load stage. There goes my week and my self-esteem 😥

I like PHP but every new tech is about all the other languages ! Recently i was searching for microservice architecture and oh it's so easy with nodejs ! It's ready made for Go ! Java has a library build in ! What about Symfony ? Laravel ?

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.

so now they even have a name for not being an idiot...

its called a "composible" architecture as apposed to a "monolith"

what if i told you it's all the same?

(i'll even throw in a bonus and say that a "microservice" architecture is still a monolith - because you need all your damn microservices working together for the full product or service anyway!!! and thats a monolith!!!!)

wow, you've "decoupled" your frontend from your backend? with this fancy thing called an "API"? well, what the hell else was anyone doing in the past decade? ITS THE SAME THING YOU DUMBASS

god i swear its 🤡 all the way down, just inventing new words for the same thing over and over again. idiots. idiots everywhere

i'm just so happy we have "composible" architectures now ❤️ thank god for that

I am starting new iteration of microservice X.
The new repository is named: new-new-new-X
And as you suspect, previous iterations are named:
new-new-X
new-X
and X
:D

How is coupling backend + frontend as a single nextjs app a good idea? What the fuck is this?

What if you have to create new replica sets of a backend because of high load pressure? What about load balancers?? What if i want my backend to be a microservice? How do i unit test the backend if its cluttered with frontend? WTF IS THIS

WHY DID NEXTJS THINK THIS IS A GOOD IDEA AND WHY DO SO MANY DEVS LOVE THIS IDEA AND GLORIFY NEXTJS?

Nextjs seems like the type of framework that was built by a frontend web developer who just refuses to learn backend technology at all costs.

---

its been a few hours and the concept of nextjs is bending my mind rn. I thought nextjs is just another frontend framework. A react killer. Only to find out its both a backend + frontend framework.

Cluttering backend stuff into frontend is gonna get messy no matter how much you try to modularize the code. Am i lost or am i right???

---

Scratching my head over nextjs. Looks like a great framework for small-mid project but definitely not large project. The more shit the project needs the more messy shit become. Angular has modularized all of this in separate folders -- components services guards interceptors (now new stuff coming called Signals) etc. All of it is separated in individual folders and kept frontend-only. Simple enough. No backend clutter

---

Can i even use nextjs strictly as a frontend framework while it uses my custom backend built in java spring boot? For example use nextjs /api/ folder to handle custom routes built outside of nextjs framework?

Am i insane here

So I just saw a post on Facebook about a "Serverless Function as a Service on Kubernetes". Could someone give me eye bleach please?

I really can't wait after Scoped Storage and how goddamn slow it is, to have a "glorified microservice" take 5 minutes to spin up a container, just to do something silly like printing a hello world. In the post it was apparently showing a QR code.. that's it. A fucking QR code, because remember it's just a function.

A whole fucking operating system that goes up and back down, just to run a goddamn fucking function!!!

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.

Got one right now, no idea if it’s the “most” unrealistic, because I’ve been doing this for a while now.

Until recently, I was rewriting a very old, very brittle legacy codebase - we’re talking garbage code from two generations of complete dumbfucks, and hands down the most awful codebase I’ve ever seen. The code itself is quite difficult to describe without seeing it for yourself, but it was written over a period of about a decade by a certifiably insane person, and then maintained and arguably made much worse by a try-hard moron whose only success was making things exponentially harder for his successor to comprehend and maintain. No documentation whatsoever either. One small example of just how fucking stupid these guys were - every function is wrapped in a try catch with an empty catch, variables are declared and redeclared ten times, but never used. Hard coded credentials, hard coded widths and sizes, weird shit like the entire application 500ing if you move a button to another part of the page, or change its width by a pixel, unsanitized inputs, you name it, if it’s a textbook fuck up, it’s in there, and then some.

Because the code is so damn old as well (MySQL 8.0, C#4, and ASP.NET 3), and utterly eschews the vaguest tenets of structured, organized programming - I decided after a month of a disproportionate effort:success ratio, to just extract the SQL queries, sanitize them, and create a new back end and front end that would jointly get things where they need to be, and most importantly, make the application secure, stable, and maintainable. I’m the only developer, but one of the senior employees wrote most of the SQL queries, so I asked for his help in extracting them, to save time. He basically refused, and then told me to make my peace with God if I missed that deadline. Very helpful.

I was making really good time on it too, nearly complete after 60 days of working on it, along with supporting and maintaining the dumpster fire that is the legacy application. Suddenly my phone rings, and I’m told that management wants me to implement a payment processing feature on the site, and because I’ve been so effective at fixing problems thus far, they want to see it inside of a week. I am surprised, because I’ve been regularly communicating my progress and immediate focus to management, so I explain that I might be able to ship the feature by end of Q1, because rather than shoehorn the processor onto the decrepit piece of shit legacy app, it would be far better to just include it in the replacement. I add that PCI compliance is another matter that we must account for, and so there’s not a great chance of shipping this in a week. They tell me that I have a month to do it…and then the Marketing person asks to see my progress and ends up bitching about everything, despite the front end being a pixel perfect reproduction. Despite my making everything mobile responsive, iframe free, secure and encrypted, fast, and void of unpredictable behaviors. I tell her that this is what I was asked to do, and that there should have been no surprises at all, especially since I’ve been sending out weekly updates via email. I guess it needed more suck? But either way, fuck me and my two months of hard work. I mean really, no ego, I made a true enterprise grade app for them.

Short version, I stopped working on the rebuild, and I’m nearly done writing the payment processor as a microservice that I’ll just embed as an iframe, since the legacy build is full of those anyway, and I’m being asked to make bricks without straw. I’m probably glossing over a lot of finer points here too, just because it’s been such an epic of disappointment. The deadline is coming up, and I’m definitely going to make it, now that I have accordingly reduced the scope of work, but this whole thing has just totally pissed me off, and left a bad taste about the organization.

More a call for discussion...

How can it be that devs constantly whine about technical debt, how everything is "ancient" bla bla bla...

Yet don't want to update libraries / stuff unless one explicitly rams an klingon pain stick up their arse because one is very very very very tired of lame excuses.

Even better example - and reason for the rant - new microservice.

They honestly started with JDK 8.

Looking at the dependencies is like walking in a museum...

OWasp Dependency check?

Lot's of 7.5s and greater (NVD score).

How brain fucked ignorant can one team be?!!!

Let alone that that thing - despite being just a skeleton project - has already 178 dependencies.

I don't want to look at the build files, I'll guess I'd turn to Freddy Krueger otherwise...

But really - why whining all the time like you have a clit / arsehole full of sand and then starting a new project with an obviously copy pasted graveyard skeleton?!

Feeling the pressure of writing back-end code for a golang microservice, after a year of fulltime front-end developement. Each commit feels like you're close to cause a bomb to detonate.

I was in charge of updating the dependencies on a microservice we have. Everything was at least 3 years old. Nice. How bad was it gonna be?

Jesus Christ, I have never felt so wrong.

A certain dependency I will hide under the name w******js allowed custom functions for a feature that accepted three arguments: paramA, paramB, paramC. The old installed version, 1.x.x, did what was intended, but for some dumb reason, 2.x.x calls the function with paramA as paramB and paramB as paramA!

It took me a god damn while to find out why shit wasn't working as expected. Who thought this was a good idea?

Working on a project in college
we thought a messenger would be cool. (Language: C# )

We decided to use a microservice architecture, rabbitMQ, .Net Core and some frameworks like EF.

My project leader changed the whole project because he is convinced that we need bleeding edge technologies if we want to create a great product. He added over 15 frameworks like MassTransit which released 10 days ago (.Net Core support).

Now we have to put a lot of effort into learning how these frameworks work instead of implementing.

How would you handle this?

Others here hates how DevOps pushed parts of operations workload on Devs? Just this afternoon I have to fix a CI issue and then find a way to connect a microservice I built to production MongoDB; I'd be okay with that (I love to thinker with servers) if not for the fact which I have to do it trough leaky and badly documented abstractions put up by the customer. I was having a nice productivity streak but when I have to do this kind of shit the motivation quickly plummets.

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.

You've got the perfect architecture lined up, a great idea about how to transition and you're about to start refactoring. Then it hits you. You've got 10 clients running your code in production and you'll have to migrate their data to the new structures, from the blob to each new microservice datastore. For each release. FML.

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?

Let's see what's on the menu today:

* Web Application Catastrophe Special *

Includes, but not limited to:
- Orphaned server processes in the configuration management cluster
- Microservice back-end architecture with no API documentation
- Poorly implemented cache microservice with no documentation
- Stale data causing everything to be shown as down in production, despite everything running fine

Cost: 1 developer's sanity

I just built a TypeScript microservice and got a heap out of memory fatal error. What the actual fuck? Micro my ass

Why do some people feel the need to prove their stupidity and utter lack of skill in the face of the world?!?!
Yesterday I learned that a sister company is hiring an intern civil engineer to code some application plugins connected to our IS ?!?!? How the fuck do you think he can only understand what the fuck we do?

To put it in context, I'm kind of the CDO of a French medium group (a little cluster of companies), as the group is in the construction industry I'm the CTO for all Computer things. Inside the group, I'm the CTO of the digital factory. So the group IS is a microservice decentralized API REST-based architecture.

Next Monday we'll have a meeting, so I can explain to them why it's a FUCKING STUPID IDEA!!!! The only good thing is that any application programming done outside of the Digital Factory will be handled as an External Company Application, so it's not my problem to secure it, debug it, or simply make it work. And they already know that I'll enforce this ruling!!!

But WHY the fuck do they still think any mother fucker can professionally program!!!!!! Every time I have to deal with them It's horrendous!!!! I had to prove them why using a not encrypted external drive for a high security mission It's stupid!!!, and why having the same password for every account is FUCKING STUPID!!!

The most ridiculous part is they have a guy who really believe he has some IT skills!! Saying things like "SVN" it's a today tool (WTF), firewall are useless, etc....

WHY!!!! WHY!!!!

Wtf is a microservice?

For a new microservice we were designing, I recently had a design discussion with a team member on creating REST endpoints for a new entity. This discussion went on for almost 3 hours, most of the time was spent on why to have two endpoints for getting this resource, one is a POST using a graphQL-like query and another one is a GET using unique ID. I said, the client-side use case is different, one is a dashboard where search results need to be shown based on multiple fields and the unique ID won't be available there because it is a system generated value, second one will be used when the unique ID is present in the client as a result of previous search result. Their responses will be similar, first returns a list of entities, second returns a single entity of the same structure.

Then came the next argument: if both APIs are returning same response, why do we need two different requests ?

It was like saying, because 5+6=11, any sum of two numbers resulting in 11 should always use 5 & 6.

Are people so frustrated of working remotely all the time that they come with such weird arguments ?

I am tired of a glorified code monkeys cosplaying software engineers.

Disclaimer: in general, I have immense respect to engineers and technological advances that came from FAANG/MANGA. Bbbuuuuttttt...

Especially people that has a few relatively short (less than a year) stints in a few of them and thinking that their salary expectation for their skills is reasonable.

What I've saw so far, based on a few hires for past few years in a company of ~50 engineers, Python/JavaScript stack, monolith to microservice transition (all people had senior and above titles):

* Have no idea how to setup own development environment on MacBook.
* Have no idea how to run code and tests for Python (from discussion, the two only development experience was "code - commit - push - done" and "clicking button in remote coding environment".
* Have no idea how to use bash/zsh (the person had "Linux skill up to 11").
* Grinding leetcode and interviewing during work hours (were let go immediately).
* Introducing a new microservice for each task (we're transitioning from Django monolith, but not to that extent).
* Ignoring all the onboarding, documentation and ignoring every request for writing documentation "I am not a technical writer".
* Knowing nothing about Kubernetes (this was in the job posting/requirements).
* Person actively hostile to any frontend task (the position is not full stack, but JavaScript is a required skill).

I am pretty open and I understand the eternal "generalist vs specialist" thing, but if the person do not posses certain skills and actively lie about it, just because "I worked at FAANG companies, obviously I have that skills" - it's dishonesty at best and fraud at worst. And if with the end of ZIRP you suddenly became unhireable in FAANG/MANGA - you need to think why.

There are tons of small software companies that nevertheless have a good salary and benefits, and most of the time hiring was a breath, because for the most of the people they were flying under the radar.

Unfortunately, since this year the hiring is exhausting, the amount of incapable candidates is incredible (a lot of them with credentials), and instead of 10-15 candidates per position (before and during pandemic), now there are more than 300 candidates per position with "impressive" working experience and only 10 people who really spend time on interviewing.

In short, if you think you're worth gold only from 3-4 companies in the world and all of them stopped hiring you - you should rethink your worth.

I can understand why in technical interviews they use those algorithmic questions. It's an incredibly short period of time to assess someone's coding capabilities. BUT can't we find a better way to do it? I mean, I've never implemented dijkstra in a work environment, and I had never heard of someone that faces those kind of problems in a normal day of work.

I may be judging by my limited information, but wouldn't be more useful to actually ask to solve a more plausible problem?

For example, create a microservice that implements this API, send us the GitHub link and the API url.

¯\_(ツ)_/¯

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

Colleague: I'll write a stored procedure that does fully qualified database table path names to access data from the other databases and then do business logic with all of it in the same proc.

Me: That will be 600 lashings.

Another team didn't bother testing their code correctly, they passed us invalid values that another microservice needs, as a result they have a bunch of unstored data (that they would have seen wasn't being stored if they bothered checking the last stage of the process to see if it was stored). Now it's been so long that the data is expired. They want us to manually store millions of transactions for them.

Now tell me...if I came and shit in your bed, shouldn't I have to clean it up?

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.

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!

Okay... I am more than annoyed. 😵😵😵 I've been trying for days to get 2 small dockerized Spring REST-Services to communicate with each other. Without docker the services work fine with each other. I've tried many tutorials, examples, hints online and so on and none works or does something else. There is so much deprecated stuff or huge tutorials where I have to install 1000 other useless things. I kinda feel like this Microservice Stuff is a myth or I'm just stupid. Even my partner has no clue.

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 ?

My laptop was at 500% of course usage and ram... Wtf...

Had to stay till 1am because I was debugging a microservice system with 15 services, 3 databases and a full mail server. Freaking integration tests took all night to build and run. Don't have a remote server to run this on because the guy is sick. Arghhhhhh

This is more of an advice seeking rant. I've recently been promoted to Team Leader of my team but mostly because of circumstances. The previous team leader left for a start-up and I've been somehow the acting Scrum Master of the team for the past months (although our company sucks at Scrum generally speaking) and also having the most time in the company. However I'm still the youngest I'm my team so managing the actual team feels a bit weird and also I do not consider myself experienced enough to be a Technical lead but we don't have a different position for that.

Below actions happen in the course of 2-3 months.

With all the things above considered I find myself in a dire situation, a couple of months ago there were several Blocker bugs opened from the Clients side / production env related to one feature, however after spending about a month or so on trying to investigate the issues we've come to the conclusion that it needs to be refactorised as it's way too bad and it can't be solved (as a side note this issue has also been raised by a former dev who left the company). Although it was not part of the initial upcoming version release it was "forcefully" introduced in the plan and we took out of the scope other things but was still flagged as a potential risk. But wait..there's more, this feature was part of a Java microservice (the whole microservice basically) and our team is mostly made of JS, just one guy who actually works as a Java dev (I've only done one Java course during uni but never felt attracted to it). I've not been involved in the initial planning of this EPIC, my former TL was an the Java guy. Now during this the company decides that me and my TL were needed for a side project, so both of us got "pulled out" of the team and move there but we've also had to "manage" the team at the same time. In the end it's decided that since my TL will leave and I will take leadership of the team, I get "released" from the side project to manage the team. I'm left with about 3 weeks to slam dunk the feature.. but, I'm not a great leader for my team nor do I have the knowledge to help me teammate into fixing this Java MS, I do go about the normal schedule about asking him in the daily what is he working on and if he needs any help, but I don't really get into much details as I'm neither too much in sync with the feature nor with the technical part of Java. And here we are now in the last week, I've had several calls with PSO from the clients trying to push me into giving them a deadline on when will it be fixed that it's very important for the client to get this working in the next release and so on, however I do not hold an answer to that. I've been trying to explain to them that this was flagged as a risk and I can't guarantee them anything but that didn't seem to make them any happier. On the other side I feel like this team member has been slacking it a lot, his work this week would barely sum up a couple of hours from my point of view as I've asked him to push the branch he's been working on and checked his code changes. I'm a bit anxious to confront him however as I feel I haven't been on top of his situation either, not saying I was uninvolved but I definetly could have been a better manager for him and go into more details about his daily work and so on.

All in all there has been mistakes on all levels(maybe not on PSO as they can't really be held accountable for R&D inability to deliver stuff, but they should be a little more understandable at the very least) and it got us into a shitty situation which stresses me out and makes me feel like I've started my new position with a wrong step.

I'm just wondering if anyone has been in similar situations and has any tips or words of wisdom to share. Or how do you guys feel about the whole situation, am I just over stressing it? Did I get a good analysis, was there anything I could have done better? I'm open for any kind of feedback.

Tips for architecture for authentication in microservice driven application.

All ms contain the code to authenticate? (Breaks single responsibly principle)

Edge level authorization?(gateway)
Service level?

Imagine filling 50 files full of garbage unreadable code to build what is essentially a cron job microservice...

Oh we have a console program
then a module to pull in all the services
then a manager to manage the actual jobs
then if they fail it all cascades back up

My god, this isn't NASA.

The amount of overengineering I have seen in the past few hours is insane.

Keep It Simple, Stupid!!!

as a seasoned systems eng myself, i had huge mental block of "i am not a programmer" whining when starting to incorperate agile/infrastructure as code for more seasoned syseng staff.

leadership made devops a role and not a practice so lots of growing pains. was finally able to win them over by asking them to look at how many 'scripts' and 'tools' they wrote to make life easier... and how much simpler and sustainable using puppet/ansible/chef/salt... and checking in all our sacred bin files and only approved 'scripts' would be pushed thru automation tool after post review.

we still are not programmers or developers, but using specific practices and source control took some time but saving us loads of time and gives us ability to actually do engineering

but just have 2 groups of younger guys that grew up wanting to be the bofh/crumudgen get off my systems types that are like not even 30... frustrating as they are the ones that should be more familiar with the shift from strictly ops to some overlap. and the devs that ask for root now that they can launch instances on aws or can launch docker containers and microservice..... ugggg. these 2 groups have never had to rack and stack servers, network gear, storage... just all magic to them because they can start 50 servers with a button click.

try to get past the iam roles, acls, facls, selinux and noshell i have been pushing. bitches.

12 factor rule is just bullshit, and microservice architecture is just hoax.

When you have to refactor the whole microservice to fix package structuring so it can be modular...why can't people do it correctly the first time?

My first rant but wanted to get it out!

New job - simple enough I think - it's a website with a login and profile that serves videos and shows your progression and asks you questions when you finish one.

Wrong - Kubernates microservice madness - functions and cosmos instances galore!

There is a full aspnetcore stack microservice with a restful API that stores..... drum roll please - a person's gender against a profile id....

Todays Architects are stupid fools.

I hate the fucking Spring WebFlux and the goddamn Project Reactor on which it depends!
Even debugging a simple CRUD microservice with simple business logic is such a pain in the ass, exception handling has a lot of "magic" implicit stuff which makes me waste hours in fucking trial & error and I have to use very little breakpoints because if a request is paused for more than few seconds it gets terminated.
I love functional programming but why shove it in fucking Java making me waste 90% of my time in trying to guessing what the fucking framework is doing, why not just use Scala which runs in the JVM? We don't even need compatibility with legacy code since it's a greenfield project!

And before you ask yes, I read a fucking book about Project Reactor and Java reactive programming and a lot of docs on Spring, Spring Boot and Spring Web Flux.

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 😄

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!

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?

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.

tl;dr:
What is a good start in go?

My wife wants to upgrade her coding skills from „I heard it at college“ to „I actually did something with it“.
I want to learn Go and start coding a bit more. My background is mostly C++ (Backend) and a bit Java (Fronted) some years ago before I went more into testing. For test automation I always use the language that makes the project happy, often Java.

We want want to join forces now, take a vacation and implement a small microservice in Go for my wife’s product (she is a PO) using pair programming.

I want to prepare that a bit. What is a good course or web tutorial to start, that some of you took and can recommend?

Thank you very much!!

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.

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 ;)

Hello fellow ranters!

So I just switched companies ( free from hell...rants if wanted) and now I'm facing a ton of new things I never worked with. Honestly I'm a little bit scared and thus I want to prepare a bit for the new stuff ahead of me. ( I'm a junior developer with only 4 years professional experience )

What are good resources to get some knowledge in the following topics, so I wont look stupid on my first day at the new company?

Docker
Microservice
DevOps ( CI/CD, Kubernetes )

I know some basic stuff to describe what these words mean but no work experience at all for these. My old work was purely monolithic Java EE 😅

Resources should be in English or German.

Thanks for every help!! 🙇🏻‍♂️🙇🏻‍♂️

Question:

For a real time chat (web) app. Whats the best technology to use for this? I dont want the chats to have delays or glitches (in case it gets sent but not delivered etc).

Backend stack is java spring boot

How about kafka? Or rabbitmq? Or socket.io? Should i use redis? Should i use AWS SQS? Talking about cloud what AWS tools should i be using to handle this the best way?

Note: it must be scalable. Meaning if i wanted to extend this software more by building a mobile app (aside from web), i should be able to use the same backend easily

Note 2: it is not ONLY a chat app. Chatting is just 1 out of many functionalities. So chatting is not the main component of the project just a side thing

Keep in mind the backend is a microservice architecture etc. Database postgresql.

need to update microservice version used by other service up multiple versions so it grabs new field i need

now im stuck debugging whether or not somebody else broke some shit, i broke some shit, or it was already broken

"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.

It's so frustrating going from being able to create a microservice stack prototype by yourself in a couple of months in your free time at home to having to wait 3 months at work for someone to add a build step in Team City so you can automate deploying a database project.

Dockerised, microservice orientated package repository like satis/npm that you can run on premises

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.

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.

Best freelancer microservice website you use with quality programmers?
We really are desperate on that.
We request some tasks and on most of the websites we don't even get an answer.
(We tried guru, Fiverr, people per hour and freelancer.com)

Why, oh god why, is our microservice component responsible for translating our output back into your obscure namespace xml format based on a Guidewire policy models? Why are we not just sending you back a Json - which is our output - and you have to figure it out into your details? Who messed this up?

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!

How would you create a mock for an Aggregator Microservice (stateless) which makes requests to other services for each request, transforms the data and then responds to the user?
I want to create a mock service where I don't t have to run the other services but it should create kinda realistic responses.
Have you had to create something like this?
I'd use it for testing another microservice that uses the aggregator.

I vaguely remember some joke about how difficult networking is and how some Jeff Atwood blog post I think makes the comparison about analogy of sending actors in a taxi to somewhere being compared to a packet, anything can happen inbetween but you will get the packet or something indistinguishable from the original at the other end if all goes well.

Are occasional/intermittent 503 service unavailable or 504 gateway timeouts unavoidable for microservices calling another external microservice?

Like at that point isn't receiving a 503 or 504 from something else, somewhat outside my jurisdriction, albeit I am fucked if I am depending on them and need to fail gracefully.

Learning how to build micro services using Spring Cloud. As I'm not familiar with this architecture, the company's lead engineer suggested me to do research & development on it, recommended me to follow official guide lines before involving me to the current under development project.

What's your advice regarding - what to keep in mind while learning micro service architecture (could be in one sentence)? It will be helpful to me. ^_^ Thank you.

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?

F@#^$$^#^&CK!
I accidentally deleted the rds instance of a microservice without final snapshoot.
No weekend to me :(

working postman request with SSL , pfx cert against microservice

go to do the same thing against different microservice , SSL error , review config, looks like im supplying same certs, etc

FML

I'd like to hear opinions from experienced devs/software architects... Referencing my two previous rants, the imposter's has been strong today. And I really don't know how to feel about the possible solution I've come up with... Adding the new feature as a microservice for an otherwise monolithic application 🙄 is that a sane idea?

The thing is I need to have a subscription type event-driven mechanism and since we're listening to service bus messages from another cloud provider, I apparently can't just have a serverless function to do the job, so unless there's a better option, I need a microservice with the subscription that can then invoke a serverless function to actually do what needs to be done. That's my idea, but I'm far from sure this is the best way...

Bit of a stupid oopsie I had today that someone might appreciate.

We’re working on a microservice project in Spring Boot, running in a docker swarm. Past few days I get a Spring Cloud config server going in separate stack, create an overlay network, and get CI deployments to use the right profiles etc. It’s looking great, and the first component is working spectacularly.

Now just to do the other 6. Move config files to the Git repo, tweak CI, all the other faffing and hoohas; and deploy. Health checks keep failing, the containers are murdering themselves and resurrecting ad infinitum. They’re doing this so quickly that by the time I get the container ID to exec in and curl health, it’s no longer running. Cue frustration, increased caffeine and nicotine consumption; my sanity is slipping.

No errors in the logs, because from experience the Cloud Config errors ar at debug level. Whhhyyyy?? Some time later (way longer than it should have been) I realize I had never actually included the Spring Cloud Config starter. Boot 101, get your starter!
Since config client is just additional setup in properties.yml, there’s no issue of the dep isn’t there, it just doesn’t try to get the config.

The containers are still unhealthy, I can hear them screaming. But now at least it’s about something else...

I got a task to work on during sprint planning on Monday. Felt the task was a 2hour task and procrastinated to do it on Tuesday. Tuesday came and I pushed it to Wednesday.

Today is Friday and I'm just realizing the task is a microservice on it's own. FML

Today I submitted to code review the first iteration of a microservice done with Ramda and flow by request of my collegues. This is the first time they look at anything similar to functional code or typed js, and only one of them took the time to actually do a review.

I really like having my code reviewed and reviewing others', but please don't pester me to make a PR for a microservice you'll never look only to bail off as soon as you see something new that scares you. Buckle up and learn new stuff!

Just because the language/feamework/technology is trendy doesn't mean it is suitable for you. There is no silver bullet in software engineering.
I think it was a big mistake to use microservice architecture for our project.

not sure what i changed, if anything

but my previously working code calling another microservice now fails because invalid jwt token

fml

So, in a microservice or web service pattern what is most important unitary test or functional test?

we need you to upgrade the microservice before you can do the product work

fml

We move to microsevice architecture to improve our web performance, Is that make sense?