5

If each cloud function or lambda function is hosted and scaled independently would it be considered a microservice?

2
  • I think the accepted term is "nanoservice"
    – Ewan
    Jan 7, 2021 at 10:40
  • 3
    @ewan: Why stop there? Let's have "femtoservices." Jan 7, 2021 at 16:18

5 Answers 5

6

They are similar

The Serverless function shares some of the same characteristics as a Microservice.

Taking AWS Lambda as example. With the AWS Lambda setting, when a client sends request, it first goes to API gateway, and then is forwarded to the Lambda function that processes the request, and sends the response back. Client is able to call the endpoint with GET, POST, PATCH,... method to trigger the Lambda function. This workflow is suggested in creating a simple Microservice using Lambda and API Gateway.

With this setting, client can

(1) send request to external API in the Lambda function,

(2) achieve communication between services, or

(3) just simply calling another Lambda function from one function (although sync call is not quite recommended, it is doable).

So it looks very similar with Microservice.

They may have different use cases

Still take Lambda as example,

  • it takes care of the backend processes and operational tasks for the user.
  • it has limitations that may block the use cases that require large amount of disk space, RAM usage, long running period. It could be a better fit for simple process task rather than a heavy data manipulation/computing one.
  • user needs to address the cold start issue if it matters.
2

Yes - a cloud/lambda function is a microservice.

Independently deployable

see https://microservices.io/

Independently deployable

https://martinfowler.com/articles/microservices.html

to describe a particular way of designing software applications as suites of independently deployable services

Microservices are "mostly" about the ability to deploy a service individually (or in a small grouping). This is the only objective aspect about microservices.

In fact, people often contrast a Microservice with a Monolithic "Project" that is deployed with all of the defined services at the same time.

Other subjective attributes:

Highly maintainable and testable, Loosely coupled, Organized around business capabilities, Owned by a small team

Yes, but there are more

GCP Cloud Function / AWS Lambda are not the only infrastructure. There are other providers, and you can also use Kubernetes and deploy each of your services as a separate task. Often people are imagining an "elastic" provider. One where they deploy and the infrastructure takes care of the scaling.

However, it is possible to view PHP files as microservices, where they run on PHP-FPM, and served via Nginx. You can create PHP files that are too big, the same that you can deploy a Cloud Function to GCP that is too big. The fact that Microservice Architecture includes good old PHP, should be a good indicator that most people are thinking of Cloud Functions and Lamda when they say "microservice" - they are thinking of that "infrastructure".

Bonus: Infrastructure Not "Architecture"

Microservice architecture is not really an architecture. The idea of breaking up services into small "loosely coupled" units has a long history in Computer Science. The only unique aspect for Microservices is how they are deployed. In total they are:

  • DevOps to deploy to elastic (per-service) infrastructure
  • The elastic infrastructure itself.

In fact, services can be contained in a single monolithic code project, run together in a programmer's development environment, and then deployed separate in production. The Deployment (DevOps) and Destination (Infrastructure) are the full extent of Microservices.

1

A microservice is a "what". A cloud function is a "how".

It's possible for a cloud function to be a microservice. It's also possible for a cloud function to not be a microservice. It depends what the function actually does.

Wikipedia has a loose definition of a microservice. I'll go through the bullet points:

  • "often processes that communicate over a network to fulfil a goal using technology-agnostic protocols such as HTTP." - check.

  • "organized around business capabilities."

    Maybe. Depends on your functions! Is it a Billing function, or is it a SendInvoice function?

    Perhaps you have SendInvoice, CalculatePrice, and UpdateBillingAddress functions, and a database, which together are one microservice (the billing microservice).

    Since cloud functions can't store data, it would be extremely rare to have one that is a microservice all by itself with no database. But it could happen! Some people consider their microservices to be stateless and treat their databases as completely separate microservices.

  • "Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best." - check.

  • "Services are small in size" - check.

  • "messaging-enabled" - check.

  • "bounded by contexts"

    Maybe. Depends on your functions. See point 2.

  • "autonomously developed"

    This is likely to be the most important defining factor. Do you have a team that works on just this function and nothing else? Or do they work on other parts of the program as well? If the function is just one part of a bigger program, then it's not a microservice.

  • "independently deployable" - check.

  • "decentralized" - check.

  • "built and released with automated processes." - check.

As you can see, cloud functions are certainly a platform on which you can build a microservice, but a thing you build on them doesn't automatically become a microservice just because it uses the platform. It has to actually be a microservice to be a microservice.

-2

For some functions, yes.

For others, no.

In essence if this function can be changed in anyway (excluding altering communication channels) will another function be required to change as well?

  • If yes, then No its not a microservice.
  • If no, then Yes its a microservice.
-2

The two concepts are orthogonal, and aren't really in the same scope. One is about how to host your code, the other is about how to structure your architecture. They are related in the sense that Cloud Lambda services are one way to write microservices, but you can do microservices in other hosts (PaaS, IaaS, bare metal) and can use Serverless code for things other than microservices.

Microservices are about dividing your architecture into separate independent services that can be provisioned and updated separately amf communicate via contracts, not shared implementation. These services can run on your own web server, on cloud VMs, on shared hosting or Serverless platforms like lambda.

Serverless/lambda is about taking PaaS to the next level. If elastic cloud computing allows you to autoscale your VMs, Serverless lets you scale at the method level, allowing your service method to scale across the provider's cloud scope, not just on pre-provisioned VMs.

The two are not the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.