Microservices are not the same thing as components Mention cloud, mention DevOps and it won’t be long before microservices enters the discussion. But what is, or are, microservices? The name implies something small – but what? Is it a part of a bigger thing or a piece of discrete functionality? And how are microservices different to application components? And why should we …
Hmmm sounds familiar to anyone who has architected CORBA/EJB2/etc... solutions or any other contained service originated architecture, what is the difference between a micro-service and a service?
Deploy many times a day, assuming the micro-service interface requirements don't change, your stack supports rolling deploys, the service have no other dependency (i.e. Enterprise DB) and your QA cycle (I would hope for full TDD and BDD automation) is up to the task? All do-able in a small green field site, but enterprise software in a team distributed across the globe, with real business requirements ...
EJB 2 ??? You must be some sort of time traveller from the distant past welcome we have beer!
The whole idea of docker and micro services is that it fits into a automated build/unit test/integration testing pipeline and you can spin up your entire environment from database to front end UI/UX with one command (see docker compose). And in fact this should be utilised as part of the end to end automated testing as that is huge leap forward.
Yes it will take some work to break up monolithic "Enterprise" applications that are tightly coupled to "Enterprise" databases that are not easy to spin up or put inside a container and not easy to test. But once your on that road you will see that maybe the old way was the problem and maybe these "Enterprise" DBs are just creating problems for application developers not solving them.
Im not even sure if its legally possible to create a container that contains something like Oracle DB. Every instance would need some kind of licence I assume. In a world where I spin up an instance of the DB populate it run tests against it multiple times in every build these types of DB are essentially ruled out.
And to be fair Im not even sure these types of DB are a good fit for software maybe there is some data warehouse type role these leviathans can play. But is there anything Oracle can do that MySQL, MariaDB, ElasticSearch, Neo4j, MongoDB, Cassandra or any number of other licence free databases cannot. I think no. But other opinions also exist.
But thats not to say there is any conflict with using micro service architecture alongside these "Enterprise" databases or even if you decide to create a container that runs some old tech like EJB2 its all up to you,
Instead of designing a system with 1 external API you build dozens of little systems each with it's own API (which you're designing as part of the overall system).
I think someone should send him a copy of the collected works of Glenford Myers.
He seems to have re packaged "composite design"
yes each with its own non public facing internal api. such as the api used to talk to a reational db.
that does not mean you need more external apis.
it also means you can look at making each micro service independently horizontally scalable for performance, resilience HA etc.
Irrelevant.
Pretty much all the data indicates a lot of trouble is caused at the "unit" level due to misunderstandings between different units and the amount of coupling between them (like Windows handle-to-windows passing a shedload of data between lots of functions, each of which can mess with any field (not just the ones they are designed to alter) to create interesting bugs to find.
So let's multiply the number of interfaces in the system and grow the testing time exponentially
Yay, I'm loving it already
Container and Microservices... too funny. Can we just bring back time shared mainframes and be done with it? Seriously, they were doing this in the 1970's and someone said: "Hey, wouldn't it just be easier to run all the pieces in one instance and make it easier to debug and more reliable?"
I learned that it's possible to model components at any level of granularity so a micro-service could be a component or it could be an application using a number of components, one of which provides a system interface.
Personally, I'd model a micro-service as a deployable unit because I come from the operational side of the house and I'd let the software people do the component mapping because they enjoy that sort of thing.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
