If I am creating an API for microservices built using multiple languages, how is it different from an API for microservices that use 1-2 technology stack. An API is the need of the business logic.
It sounds like a rookie question, but I am new to microservices and still reading up on concepts.
Related
What design patterns are commonly used or used together in developing e-commerce with microservices or multi-tier layer architecture? Let's say we will write the code using object-oriented language such as Java or .NET 5 just for an example and we develop the client app using a JavaScript framework.
Would the design patterns suggestion change if I choose to implement a microservices architecture?
There is a pattern called "Pattern: Microservice Architecture:"
Define an architecture that structures the application as a set of
loosely coupled, collaborating services. This approach corresponds to
the Y-axis of the Scale Cube. Each service is:
Highly maintainable and testable - enables rapid and frequent
development and deployment
Loosely coupled with other services -
enables a team to work independently the majority of time on their
service(s) without being impacted by changes to other services and
without affecting other services
Independently deployable - enables a
team to deploy their service without having to coordinate with other
teams
Capable of being developed by a small team - essential for high
productivity by avoiding the high communication head of large teams
Services communicate using either synchronous protocols such as
HTTP/REST or asynchronous protocols such as AMQP. Services can be
developed and deployed independently of one another. Each service has
its own database in order to be decoupled from other services. Data
consistency between services is maintained using the Saga pattern
To learn more about the nature of a service, please read this article.
And e-commerce application is considered as an example to apply pattern: Microservice Architecture.
So it is possible to create multiple services divided by entities or business domains:
customers
inventory
shipping
Then it is necessary provide the way of communication among services. It can be event streaming platform Kafka.
What is preferrable project internal structure for designing API based task.
1) Application will create API which will be acting as consumer and provider both 2) As a consumer it will integrate with multiple systems 3) Integration Systems can be SOAP based or SOA based
To answer the question which structure should the project have, you should define first:
if project is oriented on business requirements and they are being changed quite often, then it's SOA based architecture. The main difference between Service-Oriented (SOA) and Service-Based Architecture is that SOA had a "message-bus" layer, which translates business requirements to existing architecture. Service-Oriented architecture has similar topology to Microservice architecture, but services are more task/project oriented, not as small as in microservice;
if project has clear vision how API should look like and can define as a part of a tech specification, then first create an API, and then build other systems around;
second option you mentioned (As a consumer it will integrate with multiple systems) depends on project's needs, hard to say without knowing tech specifications.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
This buzzword is making me pull my hair... I have been asked to create
a microservice using .net core.
Googled a lot, different definitions and samples, but still, I don't know what makes a vs project a microservice / how can I create a microservice in VS. For example, I have asked to create a microservice where a user will input two latitude and longitude values and they will get the distance between them.
Cool, I can do this as a web project in no time. But here I need this as a microservice where the rest of the projects in our firm can use it.
What really makes a VS project into a Microservice or can I convert a project into a micro service? Microservice experts are welcome ...!!! I looking for that step by process in which a microservice is created in .net core.
A microservice is simply a concept. You won't find a "Microservice" template in Visual Studio. Generally, you're going to be implementing a REST API. A microservice doesn't have to be a REST API, but they most normally are.
You also generally won't just be making a microservice, but rather microservices. One of the core tenants of a microservice is that it should deal with just one discrete unit of functionality. Unless your application does just one very boring thing, you'll need multiple microservices. For example, for an ecommerce site, you might have a user service, a cart services, a checkout service, an order service, etc.
To coordinate the efforts of all these microservices, it's also typical to implement an API gateway. The application will work with the gateway only, and the gateway will proxy out the requests to each individual microservice to get the information or do the work that the application requires. In a sense, it acts as a conductor would, coordinating all the individual instruments to create the harmony.
Long and short, most likely what you want is one or likely more ASP.NET Core API project(s). You'll create controllers and actions on those controllers, where the latter of which will effectively become your endpoints, i.e. the functional routes your API exposes to do work. Since a microservice architecture is desired, these API project(s) should remain small and razor-focused, potentially only each working with just one entity class or maybe a very narrow slice of app functionality that involves multiple entities. You should strive to keep them as lightweight as possible, minimizing the amount of middleware and external libraries involved. When it comes to deployment, it's most typical to use containerization - Docker is a popular choice for that.
There's not really a template for creating a microservice in .NET, because any application that is deployable in a standalone way and that is reachable over some form of communication protocol (be it HTTP, message queues, or anything else) to perform some sort of action can be called a microservice.
See also Martin Fowler: Microservices and .NET microservices - Architecture e-book.
So to create your service that will "[accept] two latitude and longitude values and [return] the distance", you can simply create an ASP.NET Core Web API with one action method, and that's your microservice.
Another really good resources aside from what others have mentioned is: https://12factor.net/
It doesn't talk about any implementations (so you wont find references to .NET Core in there) but it does talk about how to design your application so it behaves more like a microservice - including dealing with scaling and processes that are stateless.
And to clarify a point of confusion: there's no special application type for a microservice. If your application behaves like a microservice, it is a microservice!
Please help in understanding
1)Choosing Akka http vs Lagom for building a microservice
2)Is there any difference between REST API and Akka http/Lagom based microservice.
Thanks
This is a very broad question, but let me give you some pointers.
1) Akka is a library (or, as the Akka team calls it, a toolkit), while Lagom is a framework. What's the difference? To quote Martin Fowler:
A library is essentially a set of functions that you can call, these
days usually organized into classes. [..]
A framework embodies some abstract design, with more behavior built
in.
Akka gives you everything you need to write a reactive microservice if you know what you're doing. Lagom tells you, to some extend, how to write a reactive microservice. For example it prescribes a certain project structure, and provides ready-made implementations for common patterns in microservices, such as service lookup, circuit breakers, asynchronous messaging, and even event sourcing and CQRS. You can do all this with Akka as well (in fact, that's what Lagom uses underneath), but you'll end up implementing a lot if it yourself. If you're not very experienced with Akka (and you probably aren't, otherwise you wouldn't be asking the question), I would recommend you give Lagom a shot.
2) A microservice is an application that is concerned with one business capability, and interacts with other microservices to form a functional system. REST is an architectural style for accessing and manipulating resources. These are completely independent, you can do microservices without REST, and REST without microservices. But you can also combine them, i.e. build your microservice as a REST service. This, or more specifically REST over HTTP and using JSON, is very common for public-facing microservices that don't only interact with other microservices, but are called from web front-ends or arbitrary client applications. So yes, there is a difference, in fact they have nothing to do with each other, but you can use Lagom (or Akka HTTP) to build a REST API.
We are developing a middleware SDK, both in C++ and Java to be used as a library/DLL by, for example, game developers, animation software developers, Avatar developers to enhance their products.
Having created a typical API using specific calls for specific functions I am considering simplifying the API by using a REST type API (GET, PUT, POST, DELETE) or CRUD type (CREATE, READ, UPDATE, DELETE) interface.
This would work in a similar way to a client-server type REST API where there are only 4 possible API calls but these can take flexible parameters.
This seems to have the benefit of making the API stable in that new calls are not being added and old calls are not being removed. So a consumer of this API need not worry about having to recompile and change their code to suit any updates to our middleware.
The overhead is that there is an extra layer of redirection in the middleware controller to route API calls and the developer needs to know what parameters are available for each REST call (supplied of course).
I have not so far seen this system used outside of web type client server applications so my question is this: Is this a feasible idea?
I am thinking in terms of its efficiency as well as if for example a game developer would find it easy to use.
Yes, this is a feasible idea. But I'm not sure the benefits would justify the costs. REST is best applied to a networked application scenario, oriented around requests and responses. While there are definite learning curve advantages to a uniform interface, those advantages can be present in almost any well-designed API which provides reasonably abstract procedures.
You also expressed concern for whether a game developer would find a RESTful API easy to use. I'd be dubious. I've implemented many RESTful web services, and helped many developers get up to speed both building them and using them, and the conceptual leap required to grasp REST can be substantial for someone who has been steeped in procedural APIs for years. I'd think that game developers in particular would be very strongly connected to procedural APIs, to the point that attempting to adopt a different paradigm, whatever its benefits, might prove extremely difficult.
Remember that REST is not specific to HTTP, and does not rely on just the 4 HTTP verbs. The verbs you have and can use depend on what protocol you're using.