4 ms·

I’ve been tracking the comments and my sense is that almost no one here believes the business domain drives the technical solution. Microservices, when constru

I’ve been tracking the comments and my sense is that almost no one here believes the business domain drives the technical solution. Microservices, when constructed from a well-designed model, provides a level of agility I’ve never seen in 33 years of software development. It also walls off change control between domains. My take from the Segment article is that they never modeled their business and just put services together using their best judgment on the fly. That’s the core reason for doing domain driven design. When you have a highly complex system, you should be focused on properly modeling your business. Then test this against UX, reporting, and throughput and build after you’ve identified the proper model. As for databases, there are complexities. Some microservices can be backed by a key-value store at a significantly lower cost, but some high-throughput services require a 12-cylinder relational database engine. The data store should match the needs of the service. One complexity of microservices I’ve seen is when real-time reporting is a requirement. This is the one thing that would make me balk at how I construct a service oriented architecture. See Eric Evans book and Vaughn Vernon’s follow up.

eksemplar 8y ago
Wait till you get older. I’ve seen the hype swing from micro services to soa and back to micro services a few times already. I think the key is doing something that works, for you, and care a little less about what other people are doing. Most paradigms have their advantages and disadvantages and it’s really just about working around that to best utilize the stuff you have.
- smadge 8y ago
  >> 33 years of software development. > Wait till you get older. Presumably someone with 33 years of software development experience is around 50 years old. How old do you think someone needs to be before they are qualified to comment on trends in software development practices? 70 years old?
  - some_account 8y ago
    He is correct though. Not only software, but lots of things are cyclical and come back in different forms. And you do have to have a few decades of life experience to be part of that. I also would totally agree that companies should never just adapt "best practices" because those leads to super complex enterprise systems which are not necessary for most companies.
  - MickerNews 8y ago
    He saw OP's argumentum ad verecundiam and raised it.
- dragonwriter 8y ago
  > I’ve seen the hype swing from micro services to soa and back to micro services a few times already. SOA and microservices are the same thing; microservices is just a new name coined when the principles were repopularized so that it didn't sound like a crusty old thing.
- ChicagoDave 8y ago
  First of all, I'm 54 and started coding at 15 on punch cards, so I've seen pretty much every paradigm in the last 40 years. It's certainly a truism that technology can be cyclical, but that's not relevant in this case. The OP's statement and article "Goodbye Microservices" is anecdotal and incorrect. I have been on teams developing microservice architectures for about six years and this particular paradigm shift has proven to be a dramatic leap forward in efficiency, especially between the business, technical architecture, and change control management. When you develop a domain model, the business can ask questions about the model. The architects can answer them by modifying the model. The developers can improve services by adopting model changes in code. This is the fundamental benefit of domain driven design and works fluidly with a microservice architecture. There's still a pervasive belief in technology circles that software should be developed from a purely technical perspective. This is like saying the plumber, electrician, and drywaller should design a house while they're building it. They certainly have the expertise to build a house, and they may actually succeed for a time, but eventually the homeowner will want to change something and the ad hoc design of the house just won't allow for it. This is why we have architects. They plan for change within the structure of a house. They enable modification and addition. Software development is no different. The Segment developers have good intentions, but they needed to work with the business to properly model everything, then build it. Granted, it sounds like they're a fast moving and successful business, so there are trade-offs. But once the business "settles", they really should go back to the drawing board, model the business, then build Segment 3.0.
lolive 8y ago
As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]
- ako 8y ago
  Reality is that the IT solution of any company consists of multiple separate applications which need to be coordinated into one working solution. From this reality it's good to design everything as if it's a (micro|macro)service part of a larger landscape of apps. Reality is also that you can never have transactions for everything across all your systems, so transaction alternatives like compensations are always something to deal with.
  - boubiyeah 8y ago
    Exactly. And there are tons of techniques to do so. For instance, Stripe is a payment service (you would think a payment service is the number one choice for transactions/locks/etc right?) implemented on the good ol unreliable internet. you can look at how they do it (idempotency, etc) Transactions are a nice and convenient shortcut when they're applicable but they're far from mandatory.
- threeseed 8y ago
  Many options exist for this e.g. Apache Curator, Redis Distlock, Ignite/Hazelcast Plus of course options around Paxos etc: https://github.com/dgryski/awesome-consensus https://github.com/dgryski/awesome-consensus
- HolyHaddock 8y ago
  You may also want to look into the Saga pattern - I found https://www.youtube.com/watch?v=xDuwrtwYHu8 https://www.youtube.com/watch?v=xDuwrtwYHu8 to be a handy high level overview for applying it to microservices. Although personally, I've never felt the need to try and apply it specifically, but the idea is interesting.
  - nomercy400 8y ago
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]

eksemplar 8y ago

Wait till you get older. I’ve seen the hype swing from micro services to soa and back to micro services a few times already. I think the key is doing something that works, for you, and care a little less about what other people are doing. Most paradigms have their advantages and disadvantages and it’s really just about working around that to best utilize the stuff you have.

smadge 8y ago
>> 33 years of software development. > Wait till you get older. Presumably someone with 33 years of software development experience is around 50 years old. How old do you think someone needs to be before they are qualified to comment on trends in software development practices? 70 years old?
- some_account 8y ago
  He is correct though. Not only software, but lots of things are cyclical and come back in different forms. And you do have to have a few decades of life experience to be part of that. I also would totally agree that companies should never just adapt "best practices" because those leads to super complex enterprise systems which are not necessary for most companies.
- MickerNews 8y ago
  He saw OP's argumentum ad verecundiam and raised it.
dragonwriter 8y ago
> I’ve seen the hype swing from micro services to soa and back to micro services a few times already. SOA and microservices are the same thing; microservices is just a new name coined when the principles were repopularized so that it didn't sound like a crusty old thing.
ChicagoDave 8y ago
First of all, I'm 54 and started coding at 15 on punch cards, so I've seen pretty much every paradigm in the last 40 years. It's certainly a truism that technology can be cyclical, but that's not relevant in this case. The OP's statement and article "Goodbye Microservices" is anecdotal and incorrect. I have been on teams developing microservice architectures for about six years and this particular paradigm shift has proven to be a dramatic leap forward in efficiency, especially between the business, technical architecture, and change control management. When you develop a domain model, the business can ask questions about the model. The architects can answer them by modifying the model. The developers can improve services by adopting model changes in code. This is the fundamental benefit of domain driven design and works fluidly with a microservice architecture. There's still a pervasive belief in technology circles that software should be developed from a purely technical perspective. This is like saying the plumber, electrician, and drywaller should design a house while they're building it. They certainly have the expertise to build a house, and they may actually succeed for a time, but eventually the homeowner will want to change something and the ad hoc design of the house just won't allow for it. This is why we have architects. They plan for change within the structure of a house. They enable modification and addition. Software development is no different. The Segment developers have good intentions, but they needed to work with the business to properly model everything, then build it. Granted, it sounds like they're a fast moving and successful business, so there are trade-offs. But once the business "settles", they really should go back to the drawing board, model the business, then build Segment 3.0.

lolive 8y ago

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

ako 8y ago
Reality is that the IT solution of any company consists of multiple separate applications which need to be coordinated into one working solution. From this reality it's good to design everything as if it's a (micro|macro)service part of a larger landscape of apps. Reality is also that you can never have transactions for everything across all your systems, so transaction alternatives like compensations are always something to deal with.
- boubiyeah 8y ago
  Exactly. And there are tons of techniques to do so. For instance, Stripe is a payment service (you would think a payment service is the number one choice for transactions/locks/etc right?) implemented on the good ol unreliable internet. you can look at how they do it (idempotency, etc) Transactions are a nice and convenient shortcut when they're applicable but they're far from mandatory.
threeseed 8y ago
Many options exist for this e.g. Apache Curator, Redis Distlock, Ignite/Hazelcast Plus of course options around Paxos etc: https://github.com/dgryski/awesome-consensus https://github.com/dgryski/awesome-consensus
HolyHaddock 8y ago
You may also want to look into the Saga pattern - I found https://www.youtube.com/watch?v=xDuwrtwYHu8 https://www.youtube.com/watch?v=xDuwrtwYHu8 to be a handy high level overview for applying it to microservices. Although personally, I've never felt the need to try and apply it specifically, but the idea is interesting.
- nomercy400 8y ago

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]