Alternatives to Ocean logo

Alternatives to Ocean

Kubernetes, AWS Lambda, Docker Compose, Serverless, and Helm are the most popular alternatives and competitors to Ocean.
5
10
+ 1
0

What is Ocean and what are its top alternatives?

It brings reliability, automation and efficiency to cloud infrastructure management for containers. It continuously analyzes how your containers are using infrastructure, automatically scaling compute resources to maximize utilization and availability utilizing the optimal blend of spot, reserved and on-demand compute instances.
Ocean is a tool in the Container Tools category of a tech stack.

Top Alternatives to Ocean

  • Kubernetes

    Kubernetes

    Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. ...

  • AWS Lambda

    AWS Lambda

    AWS Lambda is a compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can use AWS Lambda to extend other AWS services with custom logic, or create your own back-end services that operate at AWS scale, performance, and security. ...

  • Docker Compose

    Docker Compose

    With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running. ...

  • Serverless

    Serverless

    Build applications comprised of microservices that run in response to events, auto-scale for you, and only charge you when they run. This lowers the total cost of maintaining your apps, enabling you to build more logic, faster. The Framework uses new event-driven compute services, like AWS Lambda, Google CloudFunctions, and more. ...

  • Helm

    Helm

    Helm is the best way to find, share, and use software built for Kubernetes.

  • Rancher

    Rancher

    Rancher is an open source container management platform that includes full distributions of Kubernetes, Apache Mesos and Docker Swarm, and makes it simple to operate container clusters on any cloud or infrastructure platform. ...

  • Docker Swarm

    Docker Swarm

    Swarm serves the standard Docker API, so any tool which already communicates with a Docker daemon can use Swarm to transparently scale to multiple hosts: Dokku, Compose, Krane, Deis, DockerUI, Shipyard, Drone, Jenkins... and, of course, the Docker client itself. ...

  • Spring Cloud

    Spring Cloud

    It provides tools for developers to quickly build some of the common patterns in distributed systems. ...

Ocean alternatives & related posts

Kubernetes logo

Kubernetes

34.8K
29.2K
617
Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops
34.8K
29.2K
+ 1
617
PROS OF KUBERNETES
  • 154
    Leading docker container management solution
  • 123
    Simple and powerful
  • 97
    Open source
  • 74
    Backed by google
  • 56
    The right abstractions
  • 24
    Scale services
  • 18
    Replication controller
  • 9
    Permission managment
  • 7
    Simple
  • 7
    Supports autoscaling
  • 6
    Cheap
  • 4
    No cloud platform lock-in
  • 4
    Reliable
  • 4
    Self-healing
  • 3
    Promotes modern/good infrascture practice
  • 3
    Open, powerful, stable
  • 3
    Quick cloud setup
  • 3
    Scalable
  • 2
    Runs on azure
  • 2
    Cloud Agnostic
  • 2
    Backed by Red Hat
  • 2
    Custom and extensibility
  • 2
    Captain of Container Ship
  • 2
    A self healing environment with rich metadata
  • 1
    Golang
  • 1
    Expandable
  • 1
    Everything of CaaS
  • 1
    Sfg
  • 1
    Easy setup
  • 1
    Gke
CONS OF KUBERNETES
  • 13
    Poor workflow for development
  • 11
    Steep learning curve
  • 5
    Orchestrates only infrastructure
  • 2
    High resource requirements for on-prem clusters

related Kubernetes posts

Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 38 upvotes · 3.8M views

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

See more
Yshay Yaacobi

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

See more
AWS Lambda logo

AWS Lambda

15.5K
11.5K
411
Automatically run code in response to modifications to objects in Amazon S3 buckets, messages in Kinesis streams, or...
15.5K
11.5K
+ 1
411
PROS OF AWS LAMBDA
  • 126
    No infrastructure
  • 81
    Cheap
  • 68
    Quick
  • 57
    Stateless
  • 47
    No deploy, no server, great sleep
  • 9
    AWS Lambda went down taking many sites with it
  • 5
    Easy to deploy
  • 5
    Event Driven Governance
  • 5
    Extensive API
  • 4
    Auto scale and cost effective
  • 3
    VPC Support
  • 1
    Integrated with various AWS services
CONS OF AWS LAMBDA
  • 5
    Cant execute ruby or go
  • 0
    Can't execute PHP w/o significant effort

related AWS Lambda posts

Jeyabalaji Subramanian

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Tim Nolet

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

See more
Docker Compose logo

Docker Compose

13.5K
9.8K
473
Define and run multi-container applications with Docker
13.5K
9.8K
+ 1
473
PROS OF DOCKER COMPOSE
  • 119
    Multi-container descriptor
  • 108
    Fast development environment setup
  • 75
    Easy linking of containers
  • 65
    Simple yaml configuration
  • 58
    Easy setup
  • 15
    Yml or yaml format
  • 11
    Use Standard Docker API
  • 7
    Open source
  • 4
    Can choose Discovery Backend
  • 4
    Go from template to application in minutes
  • 2
    Scalable
  • 2
    Easy configuration
  • 2
    Kubernetes integration
  • 1
    Quick and easy
CONS OF DOCKER COMPOSE
  • 7
    Tied to single machine
  • 4
    Still very volatile, changing syntax often

related Docker Compose posts

Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 28 upvotes · 2.8M views

Our whole DevOps stack consists of the following tools:

  • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
  • Respectively Git as revision control system
  • SourceTree as Git GUI
  • Visual Studio Code as IDE
  • CircleCI for continuous integration (automatize development process)
  • Prettier / TSLint / ESLint as code linter
  • SonarQube as quality gate
  • Docker as container management (incl. Docker Compose for multi-container application management)
  • VirtualBox for operating system simulation tests
  • Kubernetes as cluster management for docker containers
  • Heroku for deploying in test environments
  • nginx as web server (preferably used as facade server in production environment)
  • SSLMate (using OpenSSL) for certificate management
  • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
  • PostgreSQL as preferred database system
  • Redis as preferred in-memory database/store (great for caching)

The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

  • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
  • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
  • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
  • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
  • Scalability: All-in-one framework for distributed systems.
  • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
See more

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

See more
Serverless logo

Serverless

1K
944
23
The most widely-adopted toolkit for building serverless applications
1K
944
+ 1
23
PROS OF SERVERLESS
  • 12
    API integration
  • 7
    Supports cloud functions for Google, Azure, and IBM
  • 2
    Lower cost
  • 1
    Openwhisk
  • 1
    Auto scale
CONS OF SERVERLESS
    Be the first to leave a con

    related Serverless posts

    Nitzan Shapira

    At Epsagon, we use hundreds of AWS Lambda functions, most of them are written in Python, and the Serverless Framework to pack and deploy them. One of the issues we've encountered is the difficulty to package external libraries into the Lambda environment using the Serverless Framework. This limitation is probably by design since the external code your Lambda needs can be usually included with a package manager.

    In order to overcome this issue, we've developed a tool, which we also published as open-source (see link below), which automatically packs these libraries using a simple npm package and a YAML configuration file. Support for Node.js, Go, and Java will be available soon.

    The GitHub respoitory: https://github.com/epsagon/serverless-package-external

    See more
    Praveen Mooli
    Engineering Manager at Taylor and Francis · | 14 upvotes · 1.8M views

    We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

    To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

    To build #Webapps we decided to use Angular 2 with RxJS

    #Devops - GitHub , Travis CI , Terraform , Docker , Serverless

    See more
    Helm logo

    Helm

    880
    595
    10
    The Kubernetes Package Manager
    880
    595
    + 1
    10
    PROS OF HELM
    • 4
      Infrastructure as code
    • 3
      Open source
    • 2
      Easy setup
    • 1
      Testa­bil­i­ty and re­pro­ducibil­i­ty
    CONS OF HELM
      Be the first to leave a con

      related Helm posts

      Emanuel Evans
      Senior Architect at Rainforest QA · | 15 upvotes · 607.3K views

      We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).

      We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .

      Read the blog post to go more in depth.

      See more
      Robert Zuber

      Our backend consists of two major pools of machines. One pool hosts the systems that run our site, manage jobs, and send notifications. These services are deployed within Docker containers orchestrated in Kubernetes. Due to Kubernetes’ ecosystem and toolchain, it was an obvious choice for our fairly statically-defined processes: the rate of change of job types or how many we may need in our internal stack is relatively low.

      The other pool of machines is for running our users’ jobs. Because we cannot dynamically predict demand, what types of jobs our users need to have run, nor the resources required for each of those jobs, we found that Nomad excelled over Kubernetes in this area.

      We’re also using Helm to make it easier to deploy new services into Kubernetes. We create a chart (i.e. package) for each service. This lets us easily roll back new software and gives us an audit trail of what was installed or upgraded.

      See more
      Rancher logo

      Rancher

      786
      1.2K
      644
      Open Source Platform for Running a Private Container Service
      786
      1.2K
      + 1
      644
      PROS OF RANCHER
      • 103
        Easy to use
      • 79
        Open source and totally free
      • 63
        Multi-host docker-compose support
      • 58
        Load balancing and health check included
      • 58
        Simple
      • 44
        Rolling upgrades, green/blue upgrades feature
      • 42
        Dns and service discovery out-of-the-box
      • 37
        Only requires docker
      • 34
        Multitenant and permission management
      • 29
        Easy to use and feature rich
      • 11
        Cross cloud compatible
      • 11
        Does everything needed for a docker infrastructure
      • 8
        Simple and powerful
      • 8
        Next-gen platform
      • 7
        Very Docker-friendly
      • 6
        Support Kubernetes and Swarm
      • 6
        Application catalogs with stack templates (wizards)
      • 6
        Supports Apache Mesos, Docker Swarm, and Kubernetes
      • 6
        Rolling and blue/green upgrades deployments
      • 6
        High Availability service: keeps your app up 24/7
      • 5
        Easy to use service catalog
      • 4
        Very intuitive UI
      • 4
        IaaS-vendor independent, supports hybrid/multi-cloud
      • 4
        Awesome support
      • 3
        Scalable
      • 2
        Requires less infrastructure requirements
      CONS OF RANCHER
      • 8
        Hosting Rancher can be complicated

      related Rancher posts

      Docker Swarm logo

      Docker Swarm

      681
      809
      267
      Native clustering for Docker. Turn a pool of Docker hosts into a single, virtual host.
      681
      809
      + 1
      267
      PROS OF DOCKER SWARM
      • 54
        Docker friendly
      • 45
        Easy to setup
      • 39
        Standard Docker API
      • 37
        Easy to use
      • 22
        Native
      • 21
        Free
      • 12
        Clustering made easy
      • 11
        Simple usage
      • 10
        Integral part of docker
      • 5
        Cross Platform
      • 4
        Labels and annotations
      • 3
        Performance
      • 2
        Shallow learning curve
      • 2
        Easy Networking
      CONS OF DOCKER SWARM
      • 7
        Low adoption

      related Docker Swarm posts

      Yshay Yaacobi

      Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

      Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

      After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

      See more
      Simon Reymann
      Senior Fullstack Developer at QUANTUSflow Software GmbH · | 28 upvotes · 2.8M views

      Our whole DevOps stack consists of the following tools:

      • GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
      • Respectively Git as revision control system
      • SourceTree as Git GUI
      • Visual Studio Code as IDE
      • CircleCI for continuous integration (automatize development process)
      • Prettier / TSLint / ESLint as code linter
      • SonarQube as quality gate
      • Docker as container management (incl. Docker Compose for multi-container application management)
      • VirtualBox for operating system simulation tests
      • Kubernetes as cluster management for docker containers
      • Heroku for deploying in test environments
      • nginx as web server (preferably used as facade server in production environment)
      • SSLMate (using OpenSSL) for certificate management
      • Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
      • PostgreSQL as preferred database system
      • Redis as preferred in-memory database/store (great for caching)

      The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:

      • Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
      • Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
      • Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
      • Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
      • Scalability: All-in-one framework for distributed systems.
      • Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
      See more
      Spring Cloud logo

      Spring Cloud

      650
      588
      0
      Spring helps development teams everywhere build simple, portable,fast and flexible JVM-based systems and applications.
      650
      588
      + 1
      0
      PROS OF SPRING CLOUD
        Be the first to leave a pro
        CONS OF SPRING CLOUD
          Be the first to leave a con

          related Spring Cloud posts

          Spring-Boot Spring Cloud Elasticsearch MySQL Redis RabbitMQ Kafka MongoDB GitHub Linux IntelliJ IDEA

          See more