April 1, 2015 at 8:20 pm
Comments posted to this topic are about the item Microservices for Databases
April 2, 2015 at 3:11 am
Step 1. Evangelist's sales pitch gives alternative a shite name. "Look out Monolithic applications, Microservices are coming"
Step 2. Microservices introduced, even though the last SOA attempted failed because they kept crossing bounded context (They what the what now?).
Step 3. Confused members of teams used to doing things one way for years try to [poorly] implement Microservices.
Step 4. Evangelist further confuses the team by adding CQRS to the mix."Noooo, don't read from the database you write to. For shame"
Step 5. A simple application that has been completely over engineered predictably fails, company looks for new evangelist.
Step 6. New evangelist arrives stating "Microservices are sooooo mid-2010s, everyone is using Quantum services* now"
Step 7. In the meantime the old legacy/monolith system, having had loads of T-SQL loving continues to make the customer happy...
Forgive the cynicism - Been though a similar experience for the past few years 😉
*No such thing - However if they arrive I will claim I invented them here 😀
April 2, 2015 at 4:23 am
Eoin_BI (4/2/2015)
.....Step 6. New evangelist arrives stating "Microservices are sooooo mid-2010s, everyone is using Quantum services* now"
......
*No such thing - However if they arrive I will claim I invented them here 😀
😎
Even if you mind I will steal your idea and put the lower case "i" in front and then sue you for infringement!!!! Hmmm, thinking about it some one already done it, I know I will use "my" instead: myQuantumServices TM
😛
April 2, 2015 at 4:23 am
What ever happened to SODA??
April 2, 2015 at 4:27 am
Yet Another DBA (4/2/2015)
Eoin_BI (4/2/2015)
.....Step 6. New evangelist arrives stating "Microservices are sooooo mid-2010s, everyone is using Quantum services* now"
......
*No such thing - However if they arrive I will claim I invented them here 😀
😎
Even if you mind I will steal your idea and put the lower case "i" in front and then sue you for infringement!!!! Hmmm, thinking about it some one already done it, I know I will use "my" instead: myQuantumServices TM
😛
😀
April 2, 2015 at 4:31 am
I believe that the best future lies ahead for those that create variously grained sets of SOA services. Going all out with current standard (my term) SOA services or just with microservices misses the point of each. It is the mix in granularity that will enable reuse.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 2, 2015 at 4:31 am
As for CQRS, it has little to do with different data sources in my opinion.
(I differ in opinion to Eoin The Forge but would like to nominate him for the "Comedic Post of the Day" award).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 2, 2015 at 6:02 am
RE: micro services.
"I suspect that the idea of small, loosely coupled applications, working in a service-oriented architecture,..."
What's old is new again. 🙂
This concept was promoted in the 70's and is at the heart of Unix and the myriad of "services" aka utilities described in "Software Tools" by Kernigan and Plauger.
Same concept different vehicle.
April 2, 2015 at 6:18 am
Gary Varga (4/2/2015)
I believe that the best future lies ahead for those that create variously grained sets of SOA services. Going all out with current standard (my term) SOA services or just with microservices misses the point of each. It is the mix in granularity that will enable reuse.
Is it really the granularity or is it the speed & ease at which the change can be designed,developed and then deployed? If it is the later then does it make any odds on the methodology used.
April 2, 2015 at 6:36 am
As new ideas arrive, the tried and true will continue for years to come, long after I retire anyway.
April 2, 2015 at 6:37 am
Eoin The Forge (4/2/2015)
Step 1. Evangelist's sales pitch gives alternative a shite name. "Look out Monolithic applications, Microservices are coming"Step 2. Microservices introduced, even though the last SOA attempted failed because they kept crossing bounded context (They what the what now?).
Step 3. Confused members of teams used to doing things one way for years try to [poorly] implement Microservices.
Step 4. Evangelist further confuses the team by adding CQRS to the mix."Noooo, don't read from the database you write to. For shame"
Step 5. A simple application that has been completely over engineered predictably fails, company looks for new evangelist.
Step 6. New evangelist arrives stating "Microservices are sooooo mid-2010s, everyone is using Quantum services* now"
Step 7. In the meantime the old legacy/monolith system, having had loads of T-SQL loving continues to make the customer happy...
Forgive the cynicism - Been though a similar experience for the past few years 😉
*No such thing - However if they arrive I will claim I invented them here 😀
Perfect
April 2, 2015 at 7:38 am
It seems that most public software engineering discussions revolve around the paradigm of either eCommerce shopping carts or social media. But that's just not applicable to most database applications. They do make a few points that can be adapted, like leveraging memory caching or web services where applicable. But the big picture they're trying to sell just isn't practical, unless your organization's line of business is eCommerce or social media.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 2, 2015 at 9:12 am
Yet Another DBA (4/2/2015)
Gary Varga (4/2/2015)
I believe that the best future lies ahead for those that create variously grained sets of SOA services. Going all out with current standard (my term) SOA services or just with microservices misses the point of each. It is the mix in granularity that will enable reuse.Is it really the granularity or is it the speed & ease at which the change can be designed,developed and then deployed? If it is the later then does it make any odds on the methodology used.
I think that starts spinning the OTHER wheel we often see:
1. come up with a way to complete decentralize processes and components and let them deploy freely.
2. build lots of such widget and deploy merrily
3. processes start becoming overloaded and server misbehave but no one quite knows why. The same code keeps popping up in multiple places but never quite built the same way so outcomes are a bit shaky.
4. look at all of the processes and figure out that you actually DO need some of those items that were removed earlier: standard error reporting, logging, central monitoring....
5. bring in APM, central monitoring tools; invest in expensive other options that will boost performance IF they can control the flow from a central point.
6. development becomes more complicated and deployment slow down because changing common items means more consequences to worry about.
7. start looking for ways to simplify an make processes more independent with freer deployments.
7. rinse and repeat.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 2, 2015 at 9:40 am
I'm not sure it's one way or the other. Does SOA work for banks? Probably not for some things, good gor others. It's really a decision for building a strong architecture in whatever system you use. If you need to scale out, and your requirements aren't necessarily dictacting tight coupling (I think few are), then SOA and perhaps microservices can make sense.
If the data you deal with needs strong DRI and consistency across systems, then perhaps you shouldn't be looking at distributed ideas.
The idea of SOA or microservices doesn't mean a lack of logging, reporting, or anything else. It just means contained and tightly focused.
April 2, 2015 at 10:07 am
Every time I go to a Datastax-Cassandra event, I keep hearing about the "legacy RDMS" and how NoSQL, and Cassandra specifically, are going to do them in.
After getting an idea of how Cassandra works - essentially a replicated database where space is traded for time - I have no fear of that actually happening.
Cassandra is great for solving the Netflix-sized problems (and Netflix does use Cassandra for it's data store), but would be miserable and painful to use for the other 99% of the projects that need data storage.
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply