I've used microservice architecture for years. I've also used serverless functions for years. But I've never found a neat was to present groups of serverless functions as microservices.
Server based approach
I'm a big fan of presenting HTTP APIs (internal and external) using OpenAPI specs. It enables a self-updating UI (Swagger) as well as the ability to generate SDKs.
In a server based architecture, each microservice would have its own OpenAPI spec (generated using something like Springfox, Swashbuckle etc). Then the overall system's public API Gateway would have its own spec, exposing the relevant internal calls.
Serverless equivalent?
I'm aiming to implement a serverless-microservice architecture on AWS. Replacing webserver-based logic with collections of Lambda functions isn't an issue. My question is: How do you present a collection of related Lambda functions as a microservice?
Are private gateways the right tool for the job?
I've considered using private API Gateways to present groups of Lambda functions. This would mean having a public API Gateway, pointing to multiple private Gateways. I've not seen this approach used before (which is why I question it being the optimal answer). I'd welcome any criticism of it as well as alternative ways to achieve the same thing.
My phone buzzed this morning and this Medium article popped up.
Seems to validate the private Gateway approach. Credit to Mehmet Ozkaya.
Related
I think I understand what API Mgt is and Orchestration. E.g. SAP PO and SAP CPI allow Orchestration.
I was reading the following statement:
Modern applications and changes in protocols and message designs also
started to influence the ESB. A more lightweight integration components
started to emerge, known as the API Gateway. An API Gateway doesn't
have the overhead of adapters or the complex integration functionality
of the ESB but still allows encapsulation and provides the
management capabilities to control, secure manage and report on API
usage.
Reading this is all a little vague imho. The following:
Does an API Gateway not allow for Orchestration? I think it does, as AXWAY state this in https://www.axway.com/en/products/api-management/gateway. I guess my point is what does the phrase from above "An API Gateway doesn't
have the overhead of adapters or the complex integration functionality
of the ESB ...". That said, may be such products are doing this for microServices and for the REST APIs we need to use separate products?
E.g. having read https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do it is unclear to me if orchestration of REST API's is possible with an API Gateway or if this is only for MicroServices possible?
SAP CPI is clearly Orchestration, but is it part of API Mgt or API Gateway? I think the latter.
When I look at Amazon API Gateway it states nothing about Orchestration.
I'm familiar with spring boot framework and I developed an Application which helps to handle online Assignments.I used few service classes to handle different tasks of the application and its structure can be seen here.
And I have seen several complex applications built as independent packages based on the task it do in the application.
(1)
My First question is can my Application be called as a MicroServices Application?? Because I have
used independent services for the application development.
(2)
And my second question is Can a application developed in MicroServices Architecture has MVC Architecture at the same time.But I have seen in several tutorials they are 2 different architectures.But a Moicroservices Application also has Models ,Views and Controllers at the same time.
So can those 2 be used at the same time??
Thank you!!
You should do some deeper research yourself about the concept and theory of microservices. Studying other applications without the basic knowledge can be misleading.
(1) Just because you are using multiple classes called services does not mean, you are building microservices application. Microservice application examples can be - student management rest api, question and answer management rest api, UI for administration, UI for public usage etc. All of them can be separate spring boot apps, or any other technology capable of handling the requirements (node.js, python, php, Asp.net ...) You should be able to deploy, test and use them as separate standalone apps.
(2)I think a microservice app does not need views, it can be a rest/soap app, log aggregation app, health check app, messaging service app etc. But different types can use different architecture, one of which can be MVC.
By definition of M. Fowler microservices are
..an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
As you see the definition is ambiguous. I think you are building a monolith application with a good separation of responsibilities into classes called XyServices - a possible candidates to migrate to microservices.
Microservices according to Chris Richardson
( recognized thought leader in microservices) is Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.
It is way of delivery and based on 12 factors
https://12factor.net/.
We use domain driven design as one of the way.
MVC is way of designing as service where we have model view and controller.
In Microservices architecture we can use MVC in one way where each component will be distributed .
Please go through the Microservice Patterns. It is very good book to understand the Microservices architecture
1.Answer to your question yes your application can be Microservices if it followed the 12 factors as mentioned in the website .
Yes Microservices can be on the pattern of mvc but they will be distributed and like we have Microservices for backend in similar fashion we have micro frontend for UI .
I saw in many tutorials that we need to go back to gateway and generate an entity after generating a microservice application with the same entity.
Can someone explain me, the architectural benefits of doing so?
What is the goal of generating those entities again in Gateway?
One of the points of doing that is to implement the Backend for Frontend pattern.
Basically you proxy all calls from your front-end to your microservices through the gateway. For convenience reasons the frontend is packaged together with the gateway.
JHipster just adapted the exisiting entity generators from monoliths to let users generate the backend and front-end of an entity separately on microservices and gateways respectively. Of course this is an optional feature and you are free to use it the way you want.
You can use different ways for different purposes to reach the service a microservice is offering to you. As mentioned here you don't have to use AngularJS or Angular, but you can also use React and/or Ionic.
In general you can use more than one gateway to all or only a choice of microservices per gateway (a very good example implementing different gateways is shown here).
I'm looking for open source applications that demonstrate the microservices pattern. In particular, I'd like to find one or more applications that can be spun up on real cloud environment up (but with fake data and requests) to demonstrate real-world deployment mechanics.
Unfortunately, I haven't found any good options yet. I'll note that Discourse is a modern 3-tier application, using Rails API, Ember.js, Postgres, and Redis, but it still is much closer to a monolith than an example of microservices. The closest I've found so far is https://github.com/kbastani/spring-cloud-microservice-example but that is more of a framework than an actual application that delivers data.
Not your typical CRUD app but Deis (a PaaS) uses REST APIs mostly to communicate between services. Peatio has a bunch of services that communicate asynchronously through a message queue.
Microsoft provides a demo webshop application based on .NET Core showing how to apply the microservices pattern:
https://github.com/dotnet-architecture/eShopOnContainers
There is also an ebook available: https://aka.ms/microservicesebook
this lagom application example is a microservices application written in Lagom . It is a akka based framework (DDD for design).
Application is complete and working. See if that serve your purpose.
We have a web application using Jersey and Spring's rest template. Does anyone know of a tool that can scan a code base and produce a report that lists all exposed endpoints and also internal references to those endpoints?
You may also take a look at Swagger, a framework for describing, producing, consuming, and visualizing RESTful web services.
Swagger supports multiple REST frameworks and also JAX-RS based on Jersey.
From their GitHub Wiki:
The Swagger framework simultaneously addresses server, client, and documentation/sandbox needs for REST APIs. As a specification, it is language-agnostic. It also provides a long runway into new technologies and protocols beyond HTTP.
With Swagger's declarative resource specification, clients can understand and consume services without knowledge of server implementation or access to the server code. The Swagger UI framework allows both developers and non-developers to interact with the API in a sandbox UI that gives clear insight into how the API responds to parameters and options. Swagger happily speaks both JSON and XML, with additional formats in the works.
Jersey can provide a WADL report at the /application.wadl URI. It doesn't document complex types but at least gives you a list of endpoints.
See https://wikis.oracle.com/display/Jersey/WADL