1. 20
  1.  

  2. 4

    I always feel like I’m using antipatterns when doing microservices at work, and I have no control over architectural decisions. In my team we are actually using a share nothing architecture and aws lambdas. It seems like a good idea at first but we’re not really doing team-based microservices so each feature gets its own project. Its two of us basically starting a new project for each feature request. We’re at the point now where we have our morning meetings and forget the name of the service we were working on. Not only that we get yelled at for not adding a feature to one service when the feature was requested for another service. We can’t keep up with it all.

    I am absolutely sure we are doing things 100% wrong, and there are cleaner ways to handle microservices but the naive approach we’ve taken has basically made me long for the days of having a monolith. Right now the design decisions are completely owned by management and it really annoys me that I’m pasting over an email handler with each service instead of writing it once and having different services call it as needed.

    1. 1

      You can still have shared libraries even when using microservices.

      1. 1

        I know. Through lambda layers in our case. But we don’t have an automated way to deploy them with our functions and can’t use things we can’t deploy automatically.

        Again. We ain’t right.

    2. 3

      Are you sure you’re a Scottsman?

      1. 5

        To be fair the article goes nicely in depth on the details why certain systems are not actually an independent set of services but rather lots of nodes heavily interconnected.

        1. 7

          I’d say 99% of microservice-architecture adoption is actually this — a single system where function calls are swapped out for asynchronous and error-prone network requests.

          I’m glad the author’s conclusion was to not go this route, but I don’t think the warning is dire enough.

          1. 3

            I’m glad the author’s conclusion was to not go this route, but I don’t think the warning is dire enough.

            Sconded.

            I can remember only one application in which I had something that could truly be called “microservices”. One was a service that did a geographic lookup for zip-codes, the other was an endpoint that did nothing more than checking whether or not a certain location-tracking device, with a certain authentication-hash, could upload a new (timestamp,location) pair to the database. Both were extremely simple and only required one or two hits on the database, and only required some input validation.

            I opted for plain-old-simple and reliable PHP for those services, while the more complex logic is handled in a large and mostly monolithic java-application.

            1. 2

              Yeah, that’s true.

              But I also hope this won’t scare away teams who could really benefit from splitting their architecture up and making parts swappable and independent. Makes certain things much easier to handle, in my opinion.