Product release

Elastic Cloud Enterprise 2.4: App Search, new CLI, API keys, and more

By
Anurag Gupta

Today, we are proud to announce Elastic Cloud Enterprise (ECE) 2.4. This new version includes exciting new functionality that gives users even more power in implementing their search use cases. ECE 2.4 also includes new tooling, API, and management capabilities to help operators continue to provide Elasticsearch at an enormous scale. Additionally, ECE brings updates to foundational elements for increased availability during disruptions. The new features in ECE 2.4 include:

  • App Search (Beta)
  • New command line interface: ecctl (Beta)
  • Deployment API and API keys
  • New node distribution strategies
  • New ECE proxy

Elastic App Search (Beta)

One of the most exciting features for ECE 2.4 is the ability to add Elastic App Search as part of your deployments. App Search provides a streamlined experience for building modern and relevant search experiences. From mobile applications to geo-localized search, Elastic App Search offers customization tools such as query-time synonyms and relevance tuning interfaces that cater to both technical and non-technical search managers on your team.

Elastic App Search on ECE 2.4 allows you to bring that experience to any of your deployment templates and scale out as necessary with a simple slider experience.

ECE_2.4_blog_deployment.png

New command line interface: ecctl (Beta)

Elastic Cloud Enterprise is the same software we use to power our hosted Elastic Cloud offering on top of Azure, AWS, and GCP. As our engineers operate tens of thousands of clusters in our hosted Elastic Cloud offering, we found that by building a dedicated command-line interface, Elastic Cloud Control (ecctl), on top of our existing ECE API we could streamline even more of our operations. 

With ecctl, many of the operations that traditionally required clicking in the ECE console or authenticating with the ECE API can be done using a few commands. This gives enormous value to users that want to script or automate portions of their ECE operations. Additionally, we’ve decided to open the code on GitHub, allowing you build on top or add your own commands.

This beta release only marks the first step for ecctl, and we will continue to add new releases outside ECE release cadences. Additionally, as ECE powers our Elastic Cloud offering, ecctl will also work with Elastic Cloud’s upcoming public API.

API keys and new API endpoints for managing deployments

ECE has always had a robust API that gives you the ability to manage, upgrade, and configure each component in a deployment individually. However, managing each component separately can become tedious, as in the case of upgrading. ECE 2.4 introduces a new set of API endpoints that treat deployments as a single entity, allowing you to manage the entire deployment as a whole. These can be found in the ECE API reference documentation prefixed with “Deployment.”

Additionally, ECE 2.4 also includes support for API keys that you can hand out to teams so they can view or modify deployments. These API keys include tight integration with ECE role-based access controls (RBAC), allowing admins to create unique API keys per user. Additionally, these user-specific API keys can be revoked in the case of compromise.

ECE_2.4_blog_API_key.png

New workload distribution strategies

One of the values of ECE is the robust instance distribution logic that can help maximize the utilization of resources it’s deployed on. With ECE 2.4, we are introducing three new distribution strategies to allow you to customize how deployment instances (Elasticsearch nodes, Kibana, APM Server, and App Search instances) are distributed across the available set of allocators in ECE. Here’s a list of all of the distribution strategies available in ECE 2.4: 

  • Fill First: This strategy was the one used by default in ECE versions 2.2 and below. It optimizes for maximum utilization of already used allocators before expanding to new, unused ones. It’s especially useful when running ECE on cloud environments, where customers typically only pay for provisioned capacity, since it makes sure that existing resources are fully utilized before requiring new ones to be provisioned. In this strategy, new Elasticsearch nodes and Kibana instances for a deployment are created on the least empty allocator in a given zone (even if multiple instances end up on the same allocator), making sure to fill it first before moving on to the allocator in that zone. 
  • (Default) Fill First Anti-affinity: This strategy is the default in ECE since version 2.3, and is similar to the previous one, with one change — it prefers to create instances of the same deployment on separate allocators if possible. So it’ll still try to fill an existing allocator in a given zone before moving on to the next one, but will prioritize separating instances of the same deployment onto different allocators. This strategy strikes a good balance between utilization and fault tolerance, as it minimizes the impact on a given cluster in case of a host failure.
  • (New) Distribute First: This strategy optimizes for distributing the deployment instances as evenly as possible across all available resources in a given availability zone, creating new deployment instances in the most empty allocator. This is useful in scenarios where the hardware resources are already provisioned (typically in on-premises data centers) and you want to use as much of them as possible.  
  • (New) Distribute Anti-affinity: Similar to the previous one, with one change — it prefers to create instances of the same deployment on separate allocators if possible. So it will prefer to deploy instances of the same deployment on separate allocators in a specific zone, thus minimizing the impact of an allocator failure on a given deployment. 

ECE_2.4_blog_strategies.png

New ECE proxy

One of the most important components of ECE is the proxy that most users interact with and routes all incoming cluster requests. As one of the vital layers, we’ve developed a brand new proxy layer that brings improved stability and fault tolerance to ECE, and the ability to keep routing traffic to ECE deployment even if the ECE coordination layer fails completely. Although new, this proxy implementation has already been running for a few months in production in the Elasticsearch Service, across three cloud providers and dozens of regions, handling requests for thousands of customers. It’s also worth mentioning that we have seen the new proxy as more memory- and CPU-efficient, outperforming the previous implementation. 

Lastly, this new proxy paves the way for future networking-related features and capabilities that work across ECE environments, such as cross-cluster replication. 

For a complete list of changes in ECE 2.4, be sure to check out the release notes. Interested in managing Elasticsearch at scale? You can also try out ECE for free with our 30-day trial.