DEV Community: Kalix Team

How Kalix Abstracts Away Headaches

Kalix Team — Thu, 16 Mar 2023 20:22:08 +0000

Author - The Kalix Team at Lightbend

Introduction

In general, abstraction involves removing or hiding the unnecessary attributes of something to focus on the essentials. To that end, abstraction is one of the fundamental concepts in programming that aims to reduce programming complexity by hiding the low-level (unnecessary) details of the underlying logic or implementation from users. In doing so, abstractions allow developers to design and implement complex software systems more quickly.

As programming languages continue to evolve, so do the layers of abstraction, which allow for greater reusability of code and greater code efficiency. Kalix is one of such technologies that aim to make the life of developers more manageable by using abstraction.

This post provides an overview of Kalix, what it does, and how it makes life easier for developers.

Abstraction Done Right with Kalix

Software developers today have a lot of wonderful technologies at our disposal that we can use to build robust applications. However, each of these technologies comes with unique complexity—we must understand the underlying system, how it works, and how to integrate it with our applications. This can be time-consuming and require considerable thought and effort.

Kalix is a platform-as-a-service (PaaS) microservice and API development platform that dramatically simplifies the complexities of building highly scalable, real-time applications. Kalix does this by combining an API-first, database-less, and serverless development approach to provide developers with an additional “application layer” that manages the underlying app’s properties and infrastructural needs on behalf of its users.

Kalix provides business-critical features we can use to build back-end or full-stack cloud-native applications in any programming language. It combines the necessary software components and abstracting implementation details to provide a unified and simplified application layer.

With Kalix, developers don’t have to worry about the underlying application infrastructure, such as databases, service meshes, message brokers, caches, and API gateways. These are all abstracted so developers can focus on implementing features and services. In doing so, Kalix unlocks innovation by making it easy for any full-stack or back-end developer to build high-performance, data-centric applications rapidly and at a low cost.

According to Lightbend, the company behind Kalix, the Kalix developer platform is the industry’s first and only platform enabling anyone to create large-scale, high-performance microservices and APIs without having to perform everyday operations.

Kalix Abstractions

Kalix lets us focus on what’s most important in our development processes, abstracting away several of the tedious details.

Database

In a typical serverless setting, we require a database to establish an explicit connection between the platform and an application to perform create, read, update, and delete (CRUD) operations. With Kalix, developers no longer need to worry about setting up database schemas, database management, or scaling the database as Kalix provides everything out of the box.

Kalix automatically manages the data stored in its distributed database without developers or operations personnel intervention. Kalix provides in-memory state data as needed, abstracting the complexities of database management to free developers from database maintenance.

Therefore, we do not need to be familiar with any database schemas, data caching software, or distributed data management techniques to use Kalix, which makes Kalix uniquely suited for data-centric applications.

API

Kalix understands the importance of APIs in developing serverless applications and microservices. As such, it uses an API-first approach that treats APIs as “first-class citizens'' so we can focus on API services and create data objects and structures that our services require—without worrying about how these data objects will persist.

Kalix abstracts these data objects from persistent storage to allow developers to concentrate on the API structures of their services. Using this API-first strategy, we can define how to expose the API and let the platform handle connectivity for our services.

Caching

With Kalix, we no longer need to worry about fine-tuning caching layers for our applications. The platform automatically takes care of data caching, allowing developers to focus on what we do best: developing services. This makes developing fast and performant applications a breeze.

Scalability

It is challenging to scale an application in a typical traditional hosting environment, let alone have it scale automatically. The performance of any application declines when server resources do not rise according to service demand. This may crash the application, resulting in data loss and potential business loss for any organization.

Kalix understands that it can be challenging for any organization to scale its service quickly and securely. Kalix takes care of it for us by optimizing cloud resources to automatically make data available to be processed in memory when needed. Kalix makes it easy to build microservices that scale automatically based on demand.

In addition to its highly scalable and reliable distributed computing platform, many major brands worldwide use Kalix to develop high-performance, massively scalable systems.

Benefits of Abstraction

The benefits provided by Kalix abstraction include the following.

Save Time

Developers no longer must spend time dealing with unnecessary complexities of the underlying infrastructure required by their application that have nothing to do with the problem we’re trying to solve.

Using Kalix, we can focus on business logic rather than infrastructure details such as managing databases, servers, caching, scaling, and the network. Kalix frees developers to spend more time on actual business problems, accelerating the business delivery time.

Reduce Bugs

The presence of unwanted bugs in our applications can easily break them, impact the user experience, and ultimately disrupt business operations. This could be damaging to any organization’s reputation.

As each line of code has the potential to introduce bugs into an application, writing non-vital code only increases the chances of introducing these bugs and causing issues in our applications. Fortunately, the abstraction provided by Kalix ensures fewer non-vital pieces of code, leading to fewer bugs.

Increase Deployment Efficiency

Kalix makes it possible for developers to focus more on business logic and application deployment, making it easy for development teams to rapidly move from ideation to implementation and deploy products quickly.

Additionally, a lower number of bugs and a shorter development process results in fewer issues, shorter release cycles, and quicker time to market.

Less Infrastructure

Kalix handles most of the heavy lifting, such as managing servers and databases, scaling, caching, and the underlying infrastructure—all while hiding their complexities. The platform’s model eliminates the need to predict growth and purchase equipment. As a result, we pay only for what we use.

Conclusion

Abstract specifications describe what a program does without necessarily saying how it does it. Kalix, from Lightbend, removes this nonessential information, eliminating restrictions and the need to deal with complex implementation details.

Through abstraction, Kalix allows developers to build high-performance, low-latency applications without worrying about architectural complexity, database management, or developer operations.

Moreover, its flexibility means that its microservices solution is compatible with any back end, enabling you to work in your desired language without concerns for compatibility. This also makes it cost-efficient and seamless to adopt.

If easing development, speeding time to market, and saving costs sound appealing, visit Kalix today to learn more about how their advanced microservices technology can help you transform your product offerings.

Introducing Spring SDK for Kalix

Kalix Team — Fri, 24 Feb 2023 21:01:45 +0000

Author - Renato Cavalcanti. Principal Engineer, Lightbend.

The new Spring SDK for Kalix offers a developer experience that is familiar to Spring Boot users.

It allows developers to assemble a Kalix application by annotating Java classes. Compared to other SDKs for Kalix, it frees the developer from describing their API with Protocol Buffers.

When using the Kalix Spring SDK, your services are exposed using Spring REST annotations and serialization is backed by the ubiquitous Jackson library. And, most importantly, you can start coding directly in Java.

To give you a quick preview of how it looks to define an Entity, the code below shows a Kalix ValueEntity for an imaginary Customer model:

package customer;

import kalix.javasdk.valueentity.ValueEntity;
import kalix.springsdk.annotations.EntityKey;
import kalix.springsdk.annotations.EntityType;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;

@EntityType("customer")
public class CustomerEntity extends ValueEntity<CustomerEntity.Customer> {

  record Customer(String name, String email){}
  record CreateCustomer(String name, String email){}

  @EntityKey("customer_id")
  @PostMapping("/customers/{customer_id}")
  public Effect<String> createCustomer(@RequestBody CreateCustomer create) {
    return effects()
      .updateState(new Customer(create.name, create.email))
      .thenReply("done");
  }
}

When deployed to Kalix, clients can call the service using any http client. The createCustomer method is exposed as a regular REST endpoint using Spring’s REST annotations.

To query Customers by name, you can write:

package customer;

import kalix.javasdk.view.View;
import kalix.springsdk.annotations.Query;
import kalix.springsdk.annotations.Subscribe;
import kalix.springsdk.annotations.Table;
import org.springframework.web.bind.annotation.GetMapping;
import reactor.core.publisher.Flux;

@Table("customers")
@Subscribe.ValueEntity(CustomerEntity.class)
public class CustomerByNameView extends View<CustomerEntity.Customer> {

  @GetMapping("/customers/by-name/{name}")
  @Query("SELECT * FROM customers WHERE name = :name")
  public Flux<CustomerEntity.Customer> findCustomers(String name) {
    return null;
  }
}

The Kalix Spring SDK detects all Kalix components under the main package and registers them to Kalix just as a regular Spring Boot application does.

That’s basically all that is needed to implement an Entity with query capabilities in Kalix. Just start coding!

You can try it out yourself by starting a new project using the Maven archetype or by downloading the quickstart sample.

To start a new Maven project

mvn archetype:generate  
-DarchetypeGroupId=io.kalix 
-DarchetypeArtifactId=kalix-spring-boot-archetype
-DarchetypeVersion=1.1.1`

To download a fully-functional quickstart project

kalix quickstart download customer-registry-spring`

You can find more details in the new Kalix Spring SDK documentation.

As a new feature we welcome feedback from initial users. Please contact us in the Kalix Forum with any suggestions or report issues on GitHub.

Getting Started with Kalix

Kalix Team — Thu, 16 Feb 2023 21:58:12 +0000

Author - Johan Andrén. Principal Engineer, Lightbend.

We want to show you how easy it is to get going with Kalix and how quickly you can start building high-performance APIs and microservices.

In this article we will guide you through getting started with the needed tools to create, build and deploy your first Java based Kalix service.

Creating, deploying and managing Kalix services is done through a command line utility (CLI) which needs to be installed first. Let’s start with installing the command line client.

The steps are a little bit different depending on if you are on a Windows, MacOS or Linux machine, see individual instructions for each platform in the documentation here.

Once the client has been installed, create a Kalix account by opening a terminal window and executing:

$ kalix auth login

This will open up a browser window with the Kalix log in page.

Start creating a new account by clicking “Register” or through an existing google account.

Once the account is created you will end up in a window asking you to authorize your CLI, choose “Authorize” to give the CLI permission to deploy and manage projects and services for your account.

The CLI which was waiting for this permission will now say “You are now logged in”.

Kalix services are organized into projects, to deploy a first service we need to create a project, let’s do so with our CLI executing:

$ kalix project new my-project --region gcp-us-east1

We now have an empty project called my-project created, and selected as default when deploying services.

Implementing a Kalix service is done through one of the available Kalix SDKs, you can currently build projects using the Java or Scala SDK or the TypeScript or JavaScript SDK.

To make getting started easy, the command line client provides several quickstart projects that we can start from, take a look at the available quickstarts using:

$ kalix quickstart list

Let’s download the customer-registry-java project, build and deploy it.

$ kalix quickstart download customer-registry-java
unzipping file  customer-registry/pom.xml
unzipping file  customer-registry/README.md
unzipping file  customer-registry/docker-compose.yml
unzipping file  customer-registry/src
...

Open the project in your favorite Java IDE and take a look at the protobuf service descriptors in src/main/proto and the corresponding entity service implementation in src/main/java/customer/domain/Customer.java.

We’ll deploy the project to Kalix by first compiling the Java sources and package them as a docker image, the image is then published to docker hub where Kalix will fetch it to deploy and start the service.

To continue you will have to have the following installed and available on your PATH:

A recent version of Docker
JDK 11 or later
A recent version of Apache Maven

Make sure that docker is logged in to docker hub:

$ docker login

Update the “dockerImage” property in pom.xml replacing my-docker-repo with your docker hub account name, this is where the artifact will be published.

Build, package and publish the project using maven:

$ cd customer-registry
$ mvn deploy

This will both publish the docker image to docker hub and then deploy the published image to Kalix, in the output you will see:

[info] Deploying project to Kalix
[info] Executing `kalix service deploy customer-registry johanandren/customer-registry:1.0-SNAPSHOT-20220622124847`
[info] Done.

You can use the command line to verify that the service has been deployed:

$ kalix service list
NAME                AGE   REPLICAS   STATUS   DESCRIPTION
customer-registry   82s   1          Ready

By default a deployed service is not available to the public internet, it needs to be exposed using kalix service expose customer-registry

Since this is just a sample, let’s not publish it to the world. It is also possible to create a proxy connection from your local machine, giving us access to the service without exposing it to the internet, let’s try that out:

$ kalix service proxy customer-registry --grpcui

Creating the proxy forwards port 8080 from the local machine to the running service, so we can hit it with a client, on the command line we can use curl for plain HTTP or grpcurl for gRPC calls, but the additional parameter --grpcui here gives us a nice web-UI to explore and do sample calls to our running service.

All the available methods of the deployed service can be seen in the method drop-down, each allowing triggering a call directly from your browser.

You should now be well set up to further explore what is possible with Kalix. Here are a few starting points in the documentation:

Next steps

Visit Kalix.io to learn more or register for a free trial.

Kalix: Move to the Cloud. Extend to the Edge. Go Beyond.

Kalix Team — Mon, 13 Feb 2023 23:25:32 +0000

Author - Jonas Bonér. CEO/CTO, Lightbend.

Moving to the cloud and edge comes with big rewards such as new use-cases and business opportunities.

But how to efficiently build cloud and edge applications can be a confusing journey, mainly due to the lack of managed platforms that unifies:

Developer Experience (DX) for modeling and building stateful and stateless cloud-native and edge-native applications (including consistency and query models).
ZeroOps Experience, merging the cloud and edge into a single “thing,” a cloud-to-edge continuum that provides a unified way to do system design, deployment, and operations.
Reactive Runtime that delivers ultra-low latency with high resilience throughout the whole range of cloud and edge applications by continuously optimizing data access, placement, locality, and replication.

We set out to create a powerful PaaS that addresses these challenges for the cloud-to-edge continuum. An API PaaS that enables any developer with any language to build high-performance, data-centric applications without a database.

We did it. This is the story of Kalix.

Cloud complexity is slowing down engineering teams

Cloud infrastructure today is a thriving ecosystem of products driving innovation in many areas. But cloud infrastructure is proving to be quite complex, skills are limited, and development teams are drowning in how, where, when, and even why to make use of it. Business initiatives structured on the promise of the cloud—speed to market, scalability, and cost-effectiveness—are instead faced with slower and more costly projects than projected, fraught with overwhelmed engineering teams and a growing accumulation of technical debt.

To tackle some of this complexity, Kubernetes has emerged as the de facto standard “operating system” for the cloud today; it is excellent at managing, orchestrating, and ensuring availability and scalability of empty “boxes”: the containers. But that’s only half of the story. It matters equally much what you put in these “boxes” and how you stitch them together into a single coherent system. There are too many options and decisions today, leaving developers with the task of building a complete application in a more or less ad hoc fashion. Often using tools, techniques, and patterns that they already know but are not designed for the world of these distributed systems—e.g., the cloud, microservices, Kubernetes, service meshes—setting them up for failure.

There needs to be an equal investment in the application layer to address this problem. We need to make it easier for the developer to build complete applications, bring together, complement, and take full advantage of all the excellent underlying cloud infrastructure we have at our disposal. Also, more efficient cloud infrastructure utilization results in better performing and more scalable applications, lower costs, and reduced environmental impact.

That sounds simple enough, but there are many roadblocks preventing organizations from fully embracing the value of what cloud infrastructure can provide, including managing local and distributed application data with consistency and integrity.

Managing local and distributed workflow, communication, and coordination.
Managing client context and communication.
Maintaining business rules and operational semantics of the application as a whole.
Ensuring intelligent and adaptive co-location of data, compute, and end-user.
Integration with other systems.

So, how can we help developers manage this complexity gracefully? With a programming model and a holistic Developer Experience (DX) designed specifically for the cloud and edge, working in concert with the underlying infrastructure in maintaining application properties and requirements on behalf of its users.

Serverless, sure—but no cigar

Alfred North Whitehead famously said, “Civilization advances by extending the number of important operations which we can perform without thinking of them.” This quote translates directly to software development. We are constantly climbing the ladder of abstractions, trying to do more with less, faster, and automate away as much as possible.

The Serverless DX is a considerable step in this direction and shows the way for the future DX for the cloud and edge. As I’ve said for a long time, the Serverless DX is too revolutionary to be left to Function-as-a-Service (FaaS) products. In the last year, we have seen many different products, such as databases, message brokers, and API platforms, providing a serverless DX.

It's all great and a step in the right direction, but application developers are left with many different SDKs and APIs that need to be understood how to compose, each with its own feature set, semantics, guarantees, and limitations. Creating an integration project and a new bag of challenges to maintain—end-to-end correctness, data integrity, and consistency, ensuring efficiency, scalability, and availability of the system as a whole—is all very hard. As we all know, systems most often break at their boundaries when trying to compose disparate parts into a cohesive whole.

We believe we can do better than this by taking yet another step on the ladder of abstractions and developing a unifying abstraction layer that pulls together the necessary pieces—including databases, message brokers, caches, services meshes, API gateways, blob storages, CDN networks, CI/CD products, etc.—and exposes them into one single unified programming model and DX, tailored for the cloud and edge. A programming model with well-defined and thought-through holistic semantics, ensuring end-to-end guarantees and SLAs. A programming model and Serverless DX that lets us as developers focus on the essence of value creation: building direct end-user and business value that leaves us with a coherent, understandable, predictable, and maintainable system, all managed for us in the cloud.

As Stephen O’Grady, RedMonk writes, calling for vertical integration between the application and database layers: “There are already too many primitives for engineers to deeply understand and manage them all, and more arrive by the day. And even if that were not the case, there is too little upside for the overwhelming majority of organizations to select, implement, integrate, operate and secure every last component or service. Time spent managing enterprise infrastructure minutiae is time not spent building out its own business.”

Meet Kalix!

So what is the ideal programming model and DX for cloud application development and edge computing? What is the minimum set of things developers need to be in charge of that can’t be outsourced, generated, or automated? I think it comes down to three things:

Domain data—how to model the business data; its structure, constraints, guarantees, and query model.
Business logic—how to act and operate on the data; mine intelligence, transform, downsample, relay, and trigger side-effects.
API—how to communicate and coordinate between services and the outside world, using workflow, dataflow, communication, and coordination patterns.

In Kalix, developers only have to care about these three things. They can declaratively define the API for a service (the commands and events it receives and emits), the domain data the service manages (including its constraints, guarantees, and how to query it), and then write the business logic. Once complete, push it up to the cloud, and the rest is on Kalix.

Kalix is a fully managed PaaS for building event-driven, data-centric, real-time, cloud-native applications. It’s a complete developer and zero-ops experience from start to finish. Developers never have to see or care about any underlying infrastructure, including databases, message brokers, caches, service meshes, and API gateways. It provides “vertical integration” and extends serverless by being “databaseless,” reducing complexity and time-to-market immensely. Since Kalix manages all services and underlying infrastructure pieces in the system end-to-end, it can look across them all in a holistic way, learning how they operate collectively and optimizing things at a system level (instead of at the individual service or infrastructure component level).

Kalix builds on the lessons we have learned from more than a decade of building Akka (leveraging the actor model) and our experience helping large (and small) enterprises move to the cloud and use it in the most time, cost, and resource-efficient way possible.

Nowadays, businesses get measured by their data: the quality of their data, the insights they can get from their increasing volumes of data, and the speed at which they can deliver it to their users. Speed has become a competitive advantage, getting intelligence and value from your data faster—ideally in real-time, as it “flies by.”

Kalix leverages Akka to enable this new category of applications: ultra-low-latency, high-throughput, scalable, always-available, self-healing, and self-adapting distributed applications, delivered through a simple polyglot programming model available to most popular languages today—including Java, Scala, TypeScript, and JavaScript, with Go, Python, Swift, Kotlin, and more around the corner.

Kalix: bridging the worlds of edge and cloud

We have moved closer to edge computing in the last couple of years. Today, our industry has a well-built-out edge infrastructure. Most cloud providers offer small data centers out at the edge. CDN networks allow you to attach compute to the static data served. 5G is radically changing what's possible and how customers consume data and services. The edge opens up many new exciting use-cases and possibilities for serving customers more reliably and efficiently. Examples of use-cases include emergency services, trading systems, health care, factories, autonomous vehicles, e-commerce, farming, and gaming—the list is significant and growing.

From an architectural perspective, the edge consists of hierarchical layers between the cloud and the devices; each layer is further away from the cloud but closer to the end-users. This means both new opportunities and challenges:

Further out, toward the devices:	Further in, towards the cloud:
10,000s to 100,000s of PoPs to coordinate (millions of “things” if we count the devices).	10s to 1000s of nodes to coordinate.
Unreliable networks and hardware.	Reasonably reliable networks and hardware.
Limited resources and compute power.	Vast resources and compute power.
Ability to take local, faster, but less accurate decisions.	Ability to take global, slower, but more knowledgeable decisions.
Low latency real-time streaming through in-process processing.	Batch-oriented, high latency to backend services (from the edge users' perspective).
Calls for weaker consistency guarantees (eventual or causal consistency).	Allows for stronger consistency guarantees (ACID).
More resilient and available (data, compute, and user co-located, so all needed to serve user is already there).	Less resilient and available (dependent on a fast, reliable connection to the backend cloud to send/fetch data and perform computations).
Requires fine-grained data replication and mobility (that is adaptive and selective).	Coarse-grained batch-oriented data replication is possible, and data can be stationary.

On top of all this, edge computing means orders of magnitude more user and telemetry data to manage. In fact, to this extent, Gartner predicts that by 2025, 75% of enterprise-generated data will be created and processed at the edge, compared to 10% today. That’s a lot of critical and very demanding challenges for most organizations to tackle in less than three years to try and keep pace with known and (potentially even more harmful) competitors they don’t even know of yet that are building native solutions. Organizations can’t afford to add another layer of complexity to the picture by adding a new and distinct class of products, tools, techniques, and worries to evolve and keep up.

We need to see the edge as a continuum extending the cloud. Where we simply deploy applications that can run and move seamlessly between cloud and edge layers, depending on where it is currently most efficient for them to execute. What we need is a geo-distributed cloud to edge data plane serving application data that can run anywhere: from the public cloud to 10,000s of Points-of-Presence (PoPs) out at the edge of the network, in close physical approximation to its users, where the co-location of data, processing, and end-user ensures ultra-low latency and high-throughput. A data plane consumed as a PaaS, with a single unified programming model and DX, where the question of if you are running in the cloud or at the edge is a deployment and runtime decision, not a development or architectural decision.

As discussed, low latency and high throughput are some of the most compelling advantages of edge computing. But many miss that the edge is equally much about high reliability and availability. It means that we can build applications that can continue to function without disruption in the face of failure. Applications composed of multiple autonomous services, all working independently with local data always right there, physically co-located with the end-user. Where services can communicate and share data point-to-point at the edge directly and not depend on an always-up connection back to the central cloud. This architecture (so-called local-first software) allows for highly resilient systems, systems that must run 24/7 without stopping and that can adaptively detect, react to, and cope with the failure of its parts.

Kalix is moving toward making this vision a reality. We are currently working on extending the Kalix cloud PaaS to the edge as a cloud-to-edge data plane. Soon, developers will be able to build services without worrying if they will—now or eventually—run in the cloud or at the far edge; the programming model and operational experience are the same. With Kalix, semantics throughout the cloud-to-edge continuum will be maintained and ensure that the data will always be where it needs to be (and just the data that is currently required and nothing more); always available, correct, and consistent; injected into the services on an as-needed basis, automatically, timely, efficiently, and intelligently.

With Kalix and its innovative Developer and ZeroOps Experience, powered by its low-latency and resilient Reactive Runtime, building cloud applications and extending them to the edge is now simple, just as it should be.

NOTE:

Watch the accompanying webinar Kalix: Tackling the Cloud to Edge Continuum.

Next steps

Visit Kalix.io to learn more or register for a free trial. Developers can review documentation and get started with videos here .