I was just trying to find a generic definition what are the differences between
My goal would be to implement a „real“ Microservice on Kyma - what are the key point which have been fulfilled, so that I do not „just“ implement a function?
This is a bad name that started to be used around 2013-2014. Essentially it means Service Based Architecture - you have an architecture composed of multiple services. The most important thing here is that the services can be owned by different teams and be developed, tested and deployed independently from other teams and services.
This can be AWS Lambda, Azure Functions, Google Cloud Functions, Google Cloud Run or Kubernetes Knative. The term "Functions" here are mostly a marketing term. You can deploy code consisting of one or more functions (as any other code). But it usually only runs for limited time, has a cold start penalty, it is typically only deployed on-demand when you receive an event, and you typically only pay for the running time.
"Serverless" is another marketing term for the same thing.
In my humble opinion microservices and serverless are two antagonist paradigms of running on the cloud (as of this writing 2023).
The modern approach to microservices usually involve Kubernetes, and for serverless (that would by a synonym of Lambda & Functions) you can use Google Cloud Functions or AWS Lambda.
Lambda, cloud functions, or Serverless architecture is an extreme case of microservices. Its stateless handlers of requests/messages are instantiated and called "on-demand." The lifetime of instances is managed by the related containers, which are specific to cloud providers.
Microservices are usually managed by Kubernetes. Swarm of another container orchestration platform, where autoscaling is performed as the creation of additional instances (pods in Kubernetes terminology) up to a maximum, but the minimal number of microservices is always up. Microservices, as Services handle requests in parallel in threads of the Internet Server (as Tomcat). Besides, a microservice is a Cloud Service, that has the same anatomy and engineering as REST of MVC Web Services.
Lambda /Cloud functions are created dynamically, and there can be 0 running instances where no requests occur at a period of time. The lambda function's instance is called per request by the container of a Cloud Service provider, it is just a handler.
Besides Lambda functions are closer to the Command pattern, than to real comprehension of the function: for instance, CRUD operations with domain-specific data are reasonably distinguished by an operation field in the JSON of the call. That does not mean the creation of specific functions for GET, PUT, DELETE, and UPDATE. Normally functions are called by post in HTTPS.
So, unlike microservices, the Lambda function must have a very easy and quick start with zero standup time and perform a very simple logic. DI/IOC frameworks (as Spring ) are not a good pattern here, as well as an ORM, especially with lazy initialization and/or complicated queries. The system state should be kept externally in caches (such as Elastic Cache), or KV databases (such as DynamoDB) or be logged as events (Kafka for instance). Sessions in Lambda function has another anatomy ( for instance https://medium.com/@roy-pstr/a-simple-way-to-manage-sessions-with-aws-lambda-dynamodb-in-python-c7aae1aa7258)
© 2022 - 2024 — McMap. All rights reserved.
