6 ms·

The distinct elements are they compile separately and have versioning on their API calls. No, you don't use separate microservices for writing out that text me

The distinct elements are they compile separately and have versioning on their API calls. No, you don't use separate microservices for writing out that text message. The idea is pretty simple instead of writing one big program, you write many smaller programs. It's useful around the 3 to 4 separate developers mark. It avoids you having to recompile for any minor change, allows you run the tests for just the part you changed and allows you to test the microservices in isolation. If you a production issue, the exception will be in a log file that corresponds to a single microservice or part of your codebase. Microservices are a hard form of encapsulation and gives a lot of benefits when the underlying language lacks that encapsulation. e.g. Python.

deleted 4y ago
[deleted]
Pamar 4y ago
No, you don't use separate microservices for writing out that text message. But in order to find out that Genua is the name of the port from where the cruise is departing, the appropriate time (converted to the timezone of the port, or the timezone of the client who will see this message, depending on what business rule you want to apply) and that Genua is in IT=Italy... how many microservices do I have to query, considering that port data, timezones, ISO country codes and dep.date/time of the cruise are presumably managed on at least four different "data stores"?
- anthonypasq 4y ago
  ive never seen that in practice. you dont have a database for each individual lambda. thats insanity. you can have multiple microservices point to a shared datasource, its not illegal.
  - Pamar 4y ago
    I agree, and yet most microservice zealots seem to have a different opinion on this. e.g.: https://www.baeldung.com/cs/microservices-db-design https://www.baeldung.com/cs/microservices-db-design "2.1. Fundamentals By definition, microservices should be loosely coupled, scalable, and independent in terms of development and deployment. Therefore, the database per service is a preferred approach as it perfectly meets those requirements. Let’s see how it looks:" Please understand that I have worked only on monoliths and will probably retire while still working on monoliths. This kind of absurd positions only come up when someone comes to my office with some grand plan to convert the application I work on to something "more microservice oriented".
    - ReflectedImage 4y ago
      Whilst I don't know much about cruises. Let me make up an example for you. Let's suppose we are Acme Cruise Lines running a Cruiseliner: Microservice - National Coastguard Ship Arrival System Feed Handler Database - Logs incoming messages on the feed Microservice - Asian and Australian Joint Ship Monitoring System Database - Logs incoming messages on the feed Microservice - Cruiser Arrival and Departure Times Database - Cruiser Arrival and Departures Times in a Standard Format Microservice - Customer Bookings and Payments Database - Customer Bookings and Payments Microservice - Fuel Management System Database - Ship Fuel Levels & Costs of fuel at Various Ports. It's that high level of split up. (AWS Lambdas aren't quite the same thing as microservices.)
      - Pamar 4y ago
        You are absolutely right: you do not know much about cruises. The things you listed are ... 4-5 different applications, mostly running directly on the ship(s) and what is conspicuously missing are the parts that are managed shoreside, like: Itinerary planning (your product is one or more cruises: therefore you need to preplan the itineraries, which ships to use, when you will enter each port and when you will leave it, and so on... try to imagine this like a mix between hotel management and flight company management) Inventory management (i.e. Reservation). You mention "bookings" like a microservice. This could work for ferry line, where you are basically selling a ticket for a single trip, most of the time with no personal accommodation (except maybe for the car). A Cruise booking usually comes with a ton of ancillary services (e.g. I live in Berlin and I want to take a cruise in the Caribbeans... therefore I need a flight to get there and back. This could be provided by a charter flight or a normal airline ... in either cases the ticket will be part of the booking itself) - take in account that cruise customers are mostly middle-aged or older and relatively affluent, therefore the last thing they would like to do is to create their own itinerary by booking services on 4-5 different websites. (But I suppose it is better to stop there, we are really OT now)
        ReflectedImage 4y ago
        "4-5 different websites" No, no, no. Those are internal APIs. You still only present one website to the end user.
- ReflectedImage 4y ago
  1 microservice. It's up to the software engineer to scope out the microservices properly.

deleted 4y ago

[deleted]

Pamar 4y ago

No, you don't use separate microservices for writing out that text message. But in order to find out that Genua is the name of the port from where the cruise is departing, the appropriate time (converted to the timezone of the port, or the timezone of the client who will see this message, depending on what business rule you want to apply) and that Genua is in IT=Italy... how many microservices do I have to query, considering that port data, timezones, ISO country codes and dep.date/time of the cruise are presumably managed on at least four different "data stores"?

anthonypasq 4y ago
ive never seen that in practice. you dont have a database for each individual lambda. thats insanity. you can have multiple microservices point to a shared datasource, its not illegal.
- Pamar 4y ago
  I agree, and yet most microservice zealots seem to have a different opinion on this. e.g.: https://www.baeldung.com/cs/microservices-db-design https://www.baeldung.com/cs/microservices-db-design "2.1. Fundamentals By definition, microservices should be loosely coupled, scalable, and independent in terms of development and deployment. Therefore, the database per service is a preferred approach as it perfectly meets those requirements. Let’s see how it looks:" Please understand that I have worked only on monoliths and will probably retire while still working on monoliths. This kind of absurd positions only come up when someone comes to my office with some grand plan to convert the application I work on to something "more microservice oriented".
  - ReflectedImage 4y ago
    Whilst I don't know much about cruises. Let me make up an example for you. Let's suppose we are Acme Cruise Lines running a Cruiseliner: Microservice - National Coastguard Ship Arrival System Feed Handler Database - Logs incoming messages on the feed Microservice - Asian and Australian Joint Ship Monitoring System Database - Logs incoming messages on the feed Microservice - Cruiser Arrival and Departure Times Database - Cruiser Arrival and Departures Times in a Standard Format Microservice - Customer Bookings and Payments Database - Customer Bookings and Payments Microservice - Fuel Management System Database - Ship Fuel Levels & Costs of fuel at Various Ports. It's that high level of split up. (AWS Lambdas aren't quite the same thing as microservices.)
    - Pamar 4y ago
      You are absolutely right: you do not know much about cruises. The things you listed are ... 4-5 different applications, mostly running directly on the ship(s) and what is conspicuously missing are the parts that are managed shoreside, like: Itinerary planning (your product is one or more cruises: therefore you need to preplan the itineraries, which ships to use, when you will enter each port and when you will leave it, and so on... try to imagine this like a mix between hotel management and flight company management) Inventory management (i.e. Reservation). You mention "bookings" like a microservice. This could work for ferry line, where you are basically selling a ticket for a single trip, most of the time with no personal accommodation (except maybe for the car). A Cruise booking usually comes with a ton of ancillary services (e.g. I live in Berlin and I want to take a cruise in the Caribbeans... therefore I need a flight to get there and back. This could be provided by a charter flight or a normal airline ... in either cases the ticket will be part of the booking itself) - take in account that cruise customers are mostly middle-aged or older and relatively affluent, therefore the last thing they would like to do is to create their own itinerary by booking services on 4-5 different websites. (But I suppose it is better to stop there, we are really OT now)
      - ReflectedImage 4y ago
        "4-5 different websites" No, no, no. Those are internal APIs. You still only present one website to the end user.
ReflectedImage 4y ago
1 microservice. It's up to the software engineer to scope out the microservices properly.