• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Software Mistakes and Tradeoffs: Question

 
Ranch Hand
Posts: 100
2
Python Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey authors, Welcome and Congratulations on your new book!
Question: Do we cover service-dependent tradeoffs in the book?
These days since most of all the software and applications are relying on cloud technology or a piece of dependency that involves cloud service so does that implicate tradeoffs or mistakes that we are making during the software dev cycle?

Thanks!
 
Author
Posts: 13
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Question: Do we cover service-dependent trade-offs in the book?


Yes, some chapters focus on lower-level (code) trade-offs, but some focus on more architecture (service-dependent) trade-offs.
For the latter category, you may look into the chapters:
- Code duplication is not always bad: Code duplication vs. flexibility
- Balancing flexibility and complexity
- Leveraging data locality and memory of your machines
- Consistency and atomicity in distributed systems
- Delivery semantics in distributed systems
- Managing versioning and compatibility
 
Marshal
Posts: 79416
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How much do you say about when code duplication would be OK?
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Code duplication is a really interesting topic. I've had lots of conversations about the merits (or not) of code duplication with the microservices crowd.

It's long been the generally accepted wisdom that code duplication is bad, and part of the job of a responsible developer is to minimise it. That only really makes sense in the context of a single application, though.

When you have separate applications with their own development teams or life-cycles, a reliance on shared code can cause all kinds of complications and slowdowns. It can often be much more productive to develop  each separate application independently, even if that leads to duplication. In particular the aim with the microservices approach is that you should be able to throw away and rewrite any of the microservices without affecting any of the others.

This is a really nice idea, but just as with any other software development, you need to be aware of the technical debt inherent in the duplication. If a commonly-used external service changes its API or semantics, for example, then every service which uses it needs to be updated to conform. With shared code that might be an easy fix in one place, but with a system which consists of a soup of microservices, the same change may need to be made in slightly different ways in several different places, which is obviously a lot more risky and harder to test.
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Frank Carver wrote:Code duplication is a really interesting topic. I've had lots of conversations about the merits (or not) of code duplication with the microservices crowd.

It's long been the generally accepted wisdom that code duplication is bad, and part of the job of a responsible developer is to minimise it. That only really makes sense in the context of a single application, though.

When you have separate applications with their own development teams or life-cycles, a reliance on shared code can cause all kinds of complications and slowdowns. It can often be much more productive to develop  each separate application independently, even if that leads to duplication. In particular the aim with the microservices approach is that you should be able to throw away and rewrite any of the microservices without affecting any of the others.

This is a really nice idea, but just as with any other software development, you need to be aware of the technical debt inherent in the duplication. If a commonly-used external service changes its API or semantics, for example, then every service which uses it needs to be updated to conform. With shared code that might be an easy fix in one place, but with a system which consists of a soup of microservices, the same change may need to be made in slightly different ways in several different places, which is obviously a lot more risky and harder to test.



Hi Frank, in our company, we use shared libraries between projects to avoid code duplication. Such libraries are statically packaged in each microservice. It does create a dependency that should managed when such library has to be modified (versioning is mandatory), not to mention the lack of a central responsible team to manage the issues. What do you think about that corporate strategy to deal with sharing code?
In time, i'm looking forward to read the book.
 
Tomasz Lelek
Author
Posts: 13
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

Hi Frank, in our company, we use shared libraries between projects to avoid code duplication. Such libraries are statically packaged in each microservice. It does create a dependency that should managed when such library has to be modified (versioning is mandatory), not to mention the lack of a central responsible team to manage the issues. What do you think about that corporate strategy to deal with sharing code?
In time, i'm looking forward to read the book.



This exact problem is discussed in the 2nd chapter. Regarding strategy for sharing the code - the proper tooling (artifact repository), proper publish model with semantic versioning, and keeping the backward compatibility between versions would make the life of both maintainers and clients of the library easier.
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Likes 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Tomasz on this one.

The most effective shared code libraries I have used have been run like open source projects, even if they have been inside a corporate firewall.

The key things to remember when maintaining an open source project are that:
  • you don't know who all of your users are
  • you can't assume everyone is using it the way you do or for the purpose you do.

  • When you work through the implications of those statements, you realise that you need proper versioning and API documentation, and you can't casually change something just because it works better for you.
     
    Saloon Keeper
    Posts: 27865
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    To condense that down a little, versioned libraries are at the heart of the Maven system and are expressly intended to manage just that sort of problem. You additionally can use the same Maven repositories in Ant with Ivy and with Gradle, among other builders. You can run a local repository server for Maven that will not only cache global libraries are they are pulled (reducing load on the Internet), but also house locally-developed proprietary libraries and even manage "snapshot" development versions.

    That does well for Java. Other platforms are more hit-and-miss. There is versioning support for Python and for JavaScript, but I don't know about their local repository options. Perl does too, I think - in theory. In practice, one reason I mostly abandoned Perl for Python was the frequent breakage of Perl archives unde CPAN.

    C is pretty hopeless, although in Unix/Linux, if you build an object (.so) file, you can version them by name and even bundle them into OS installation packages. Windows originally didn't support versioning or multiple concurrent library  versions in a system, and although I think I may have heard of improvements there, I cannot swear to them,

     
    I want my playground back. Here, I'll give you this tiny ad for it:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic