Sorry about the clicking sound -- my microphone died and it's picking up the sound of the camera autofocusing :(. *shame* *sadness* *etc* I'll spend this week re-recording the other videos I made on this same day.
i know Im asking randomly but does anybody know of a tool to get back into an Instagram account..? I was dumb lost my login password. I would appreciate any tips you can offer me.
@Randall Billy I really appreciate your reply. I found the site on google and im in the hacking process now. Takes a while so I will get back to you later when my account password hopefully is recovered.
I work in a large corporate environment. In my experience, most newly minted "architects" sell the idea of microservices. The reason most often given is that it would solve the current performance problems with the monolith. Often the problems with the existing monolith is its poor design, a well engineered monolith could solve the problem. But, selling the idea of replacing one monolith with another, despite the newer being a better engineered one is hard. But selling microservices is easy, because you know - it works at Google and Amazon.
team lead of a 4 person team in an area with 16 devs working on the same product. We used to, and occasionally still do, run into problems where multiple people deploy the same service in the same sprint and have to work together. But the more we've broken off into microservices the less we face this. But the more we've had to face a mess of retries, failovers, and system maps requiring additional tech like distributed trace. You also end up with a ton of services that have no performance issues and a few leaf nodes that still need heavy optimization and back up the system with retries, db load affecting other services, etc.
I think there are 2 main problems with microservice architecture: 1. The "silver bullet" way of thinking about it: if we do MS all of our problems will be solved, scalability, etc.... 2. "Let's make a MS for everything" so people end with 100's of MS and everything is a chaos There is no such thing as silver bullet and making everything a "micro", I'm more inclined to use "domain driven development", so instead of a "micro" just write a service. We can end with 5 or 6 services and is a reasonable amount, it can still be scalled, have separated teams for the services and is not as hard to deploy as 100's of micros...also what works for one company does not work for others...just my 2 cents
Microservices might be expensive from a devops/SRE perspective, but I think the pros outweigh the cons from a software architecture POV. It is better to build your applications to scale easily rather than having to rebuild everything when your user base becomes large. Most businesses want to grow their customer/user base, why would they not prepare to scale up? Implementing microservices is like laying a good foundation for the future.
You have not even made an argument for me to counter? How are micro services a “good foundation”? What if you have to lay off 1/2 your staff, how are you now supposed to manage the mess of micro services you have?
@@darkpill just because it’s microservices does not mean that each microservice is built by a separate team. Microservices allow multiple teams to work somewhat independently, but it’s possible for one team/individual to create all the microservices. Microservices is not a management style, it’s application architecture. The good foundation is the ability to scale without needing to be rebuilt later on.
If parallel development is the only real benefit for you, you could save yourself the networking overhead by having the services communicate through IPC. That way you would just treat it as a monolith from a networking/scaling perspective but develop it as a microservice architecture.
Distributed development can also be done using Monolith architecture with some workaround, I've implemented already in Backend & Android Projects. I've split my monolith Backend repository into multiple repositories each repository is independent and development can be done by a different person/team without giving access to other features/repositories, using a feature of git called git-submodule and when final deployment comes we use all repositories combined at build-time and produce a full-fledged Application. This is awesome, I've implemented this architecture in Android & Laravel projects. Our main goal was to hire resources part-time to develop some features or modules and we didn't want to share our existing codebases with those part-time workers. Thanks.
I've been wondering about this from a non-developer perspective. The way I see it, you're siloing APIs which you would also do in a monolith. One benefit I see, that you didn't mention, is dependency management.
I don't think so. There's interdependence between microservicesand interdependencies in the way they communicate. In order to make changes, there's a lot of bureaucracy. to the point that people just try to hack it in some ways.
Well put! Thanks for sharing your thoughts about it. What's bugging me most currently is the large amount of "stuff" that has to be done around the core business logic within a single microservice - repository, documentation, glue/"ceremony" code, e.g. for upstream service calls, logging/monitoring, the security setup, build and deployment pipelines, quality report execution, and so on. I.e. redundant stuff that increases maintenance costs. We can escape this but only by investing into the creation of shareable, standardized components reused by all our microservices, e.g. in the form of Spring Boot starters. I'll try to push this as much as possible in my context. Pressure is high in creating ever smaller components in our application architectures. It will be the art of finding the right balance between too microservices and moduliths that are simple enough to be effective in maintaining and extending them.
In addition to having the ability to distribute work on codebases, you can have codebases in different languages / versions / dependency library versions. Even though your programming language is likely Turing complete, that doesn't mean it is the right tool for the job. SImple webserver might be quicker in Python vs. Kafka consumer might work better in Java. Also, I don't think you need to scale to massive proportions in order to benefit from scaling abilites. Compute intensive batch jobs running for an hour every day don't require for the expensive infra to be paid the other 23 hours sitting and doing nothing.
Good to hear someone talk common sense on some of these behemoth developed techs once in a while. A lot of us are working on small sites and apps that will never need things like Kubernetes or even Docker. Imagine if some guy who struck gold making $500 sites went around preaching about his custom tech called *Matchbox* or something. It might be handy for small guys like himself who scratch out a living from local stores. But it's gonna be found out at the medium sized company level. And the big boys will use the tech name as an insult. "Keep away from those guys - they're just Matchboxers!" 😂
The problem is somewhat resolved since every design service states "simplify". The minimum data for the user. Don't do to much. This then reflects in the GUI and application in that it does the bare minimum. This means we now have loads of s4it applications that are "easier" to scale and distribute. Yeah! And still they fail all the time. Oh well. We are where we are; tilting at windmills. Thanks for sharing!
I’ve seen microservices done extremely well and realized great benefits. I’ve also seen them done poorly. Microservices are not a cure for poor architecture and poor leadership. As a DevOps leader, I don’t ever want to go back.
It does not matter if microservices are done well if it is not needed. Like he said. 99% of the time the companies that do microservices, do not actually have the number of users to justify its use.
@@FrankLloydTeh my Unix has only one user. But the Unix philosophy of making small utilities that do one thing very well and share a universal interface is not wasted. That’s what microservices are.
At what point does the containerized mindset going to tip into utter complexity? A rats nest of trying to decipher...a wonderful thing of beauty for hackers
i don even know how no one has made a video this before. it's Obvious that modularizing and distributing an application has a very Limited and Specific Context to be made Efficient. It is only Justified indeed Only in a very Particular Application context. That is very Large applications with Multiple Interfaces to Several, let's call them, "interactions". That is very large systems that interact with a very big number of Different platforms and services. Other then that forget it ... it's a complete Waste of resources, scalability and efficiency.
these days they hire 2 architect, one team lead, one tech lead, one project manager, devops, 2 backend coder and 1 full stack coder that do all the actual work until they fire him because hr have problem with their crappy micro-architecture... they are so proud of their overly-architectured CRUD microcrap.. they dont even see that normal backend coding is actually nothing complex and just crud op, optimized queries and sometimes caching..
I don't want to be too cynical, but I would not be surprised if developer replaceability plays a big role in the decision of using microservices. Just my 2 cents.
I feel like under the hood, the promise with microservice was that developers would not break the codebase, because it was separated. They thought that if they divided the application up, they wouldn't need to worry about spaghetti code and everything would be faster. I feel like this was the original ideia, but... i don't think it solved the problem. it just made it worse. Soon enough we'll have a spaghettis of microservices. Just wait and see.
YES!!! Mine 10 year expirience of web+enterprice development support this. `docker-stack` suck. Every `fork` of this stack, espessiall `kube-stack` suck as well. But if implementation suck, idea still is really good. IT should start using erlang for 20 years ago. Then we would have had rigth implementation of microservices.
Maybe github.com/odrotbohm/moduliths... I'm currently building microservices based architectures, but I'm also more reluctant than others to split up functionality too early, as I fully buy into the YAGNI principle here, as mentioned by Frank. I was playing with the idea to try the modulith approach, but haven't been able to do so yet. One reason I'm reluctant is that a modulith takes more discipline to keep the architecture clean than a more enforced separation with multiple microservices. It boils down to scaling the organization, as described in en.wikipedia.org/wiki/Conway%27s_law
Everyone keeps asking how we plan on containerizing these elements, and I am like... bro, they run on a few scripts at boot time. Please stop hearing buzz words and forcing silly changes that help nothing.
All i can tell you at this point is i HATE microservices. What ends up happening is you call them "micro" and they aren't. They are megaservices. We have a system with very complex interactions that one user interaction can cause a cascade of changes to happen. Things can and will fail and if they fail you have "weird" things happen that can't be explained. Because you have a bunch of diseperate services you lose the security blanket of a transaction (unless you want to deal with the mess that is distributed transactions). Your users are breathing down your neck with scenarios that happened & want to know "how could this happen" & won't take "can't repro" as an excuse so you end up happen to come up with well if we had a timeout here (& at the same time trying to correlate error logs) and if this happened at the same time. IMO micro services should be TINY and should be bounded to a "bounded context". If you see a bunch of interaction for your microservices to other microservices your doing it wrong.
Yeah, doing microservices right is really tough. Operationalizing them -- instrumenting them, securing them, monitoring them, and troubleshooting them -- is even harder. Good design is hard. I agree that monoliths work better for what most companies (not the world's largest companies, but most companies) are doing.
... and the reason behind what you said is that programmers today are far less skilled compared to programmers even 20 years ago, due to massive commodification of the profession in recent years
