Alternatives to Apache JMeter logo

Alternatives to Apache JMeter

Testrail, BlazeMeter, Selenium, Postman, and Gatling are the most popular alternatives and competitors to Apache JMeter.
417
278
+ 1
10

What is Apache JMeter and what are its top alternatives?

Apache JMeter is a popular open-source tool designed for load testing and performance testing, used to analyze and measure the performance of web applications. Key features of Apache JMeter include the ability to test websites, web services, databases, and FTP servers, support for various protocols such as HTTP, FTP, JDBC, and LDAP, and the capability to generate dynamic and customizable test plans. However, Apache JMeter may have a steep learning curve for beginners, limited reporting capabilities, and may require significant resources for large-scale testing.

  1. Gatling: Gatling is a highly efficient open-source load testing tool built on Scala and Akka, offering a high-level DSL for performance testing. Key features include support for various protocols such as HTTP, websockets, and JMS, real-time reporting, and code reusability. Pros of Gatling compared to Apache JMeter include better performance for high-concurrency scenarios and a more developer-friendly approach, while cons may include a steeper learning curve for some users.

  2. K6: K6 is an open-source and developer-centric load testing tool that enables performance testing from the early stages of development. Key features of K6 include script flexibility with JavaScript, cloud-based test execution, support for running tests locally or on the cloud, and powerful CLI capabilities. Pros of K6 compared to Apache JMeter include ease of use, scalability for large loads, and better integration with modern CI/CD pipelines, while cons may include limited protocol support.

  3. Locust: Locust is an open-source load testing tool that allows users to write Python scripts to define user behavior, making it highly scalable and flexible. Key features of Locust include distributed load generation, support for scripting in Python, real-time monitoring, and an easy-to-use web interface. Pros of Locust compared to Apache JMeter include flexibility in defining user behavior, horizontal scalability for large loads, and an intuitive web interface, while cons may include limited protocol support and a need for Python programming skills.

  4. Artillery: Artillery is an open-source load testing tool designed for testing modern applications and services with a focus on simplicity and flexibility. Key features of Artillery include a declarative YAML DSL for test scenarios, real-time reporting, and support for testing websockets and HTTP/1.1/2.0. Pros of Artillery compared to Apache JMeter include ease of use, flexibility in defining test scenarios, and support for modern application architectures, while cons may include limited protocol support and a smaller user community.

  5. Blazemeter: BlazeMeter is a commercial load testing platform that offers scalability, reliability, and integration with various tools for performance testing. Key features of BlazeMeter include simple test script recording, integration with popular tools like Jenkins and JIRA, real-time reporting, and support for various protocols. Pros of BlazeMeter compared to Apache JMeter include scalability for large loads, cloud-based test execution, and integration with popular DevOps tools, while cons may include cost for enterprise features and limited customization options.

  6. LoadNinja: LoadNinja is a commercial load testing tool that offers scriptless scenario creation, comprehensive real-time reporting, and browser-based load testing. Key features of LoadNinja include support for a wide range of browsers, visual test script creation, and integration with various CI/CD tools. Pros of LoadNinja compared to Apache JMeter include ease of use with a scriptless approach, realistic load testing scenarios, and browser-based load generation, while cons may include cost for enterprise features and limited protocol support.

  7. NeoLoad: NeoLoad is a commercial load testing tool designed to test all digital applications, including web applications, mobile apps, and APIs. Key features of NeoLoad include a user-friendly interface, support for various technologies, integration with popular CI/CD tools, and real-time analytics. Pros of NeoLoad compared to Apache JMeter include ease of use with a user-friendly interface, advanced analytics capabilities, and broad technology support, while cons may include cost for enterprise features and the need for additional training.

  8. LoadRunner: LoadRunner is a commercial load testing tool designed for testing a wide range of applications and protocols, including web, mobile, and enterprise applications. Key features of LoadRunner include a comprehensive suite of testing tools, real-time analytics, support for a wide range of protocols, and integration with popular CI/CD tools. Pros of LoadRunner compared to Apache JMeter include broad protocol support, comprehensive testing capabilities, and integration with enterprise systems, while cons may include cost for enterprise features and a steeper learning curve for beginners.

  9. Tsung: Tsung is an open-source distributed load testing tool built on Erlang, designed for stress testing and performance testing of web services. Key features of Tsung include support for HTTP, WebSockets, embedded language extendibility, and event-driven architecture. Pros of Tsung compared to Apache JMeter include scalability for large loads, distributed testing capabilities, and support for modern web technologies, while cons may include a steeper learning curve for some users and limited protocol support.

  10. Taurus: Taurus is an open-source automation-friendly tool that wraps and enhances popular testing tools like JMeter, Gatling, and Selenium. Key features of Taurus include support for multiple testing frameworks, integration with CI/CD tools, real-time reporting, and flexibility in defining test scenarios. Pros of Taurus compared to Apache JMeter include ease of use with a simplified configuration format, support for various testing tools, and integration with DevOps pipelines, while cons may include limited customization options and a need for familiarity with underlying testing tools.

Top Alternatives to Apache JMeter

  • Testrail
    Testrail

    TestRail helps you manage and track your software testing efforts and organize your QA department. Its intuitive web-based user interface makes it easy to create test cases, manage test runs and coordinate your entire testing process. ...

  • BlazeMeter
    BlazeMeter

    Simulate any user scenario for webapps, websites, mobile apps or web services. 100% Apache JMeter compatible. Scalable from 1 to 1,000,000+ concurrent users.<br> ...

  • Selenium
    Selenium

    Selenium automates browsers. That's it! What you do with that power is entirely up to you. Primarily, it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) also be automated as well. ...

  • Postman
    Postman

    It is the only complete API development environment, used by nearly five million developers and more than 100,000 companies worldwide. ...

  • Gatling
    Gatling

    Gatling is a highly capable load testing tool. It is designed for ease of use, maintainability and high performance. Out of the box, Gatling comes with excellent support of the HTTP protocol that makes it a tool of choice for load testing any HTTP server. As the core engine is actually protocol agnostic, it is perfectly possible to implement support for other protocols. For example, Gatling currently also ships JMS support. ...

  • Locust
    Locust

    Locust is an easy-to-use, distributed, user load testing tool. Intended for load testing web sites (or other systems) and figuring out how many concurrent users a system can handle. ...

  • JavaScript
    JavaScript

    JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...

  • Git
    Git

    Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. ...

Apache JMeter alternatives & related posts

Testrail logo

Testrail

196
259
30
Efficiently manage, track and organize your software testing efforts
196
259
+ 1
30
PROS OF TESTRAIL
  • 10
    Designed for testers
  • 6
    Easy to use
  • 5
    Intutive
  • 5
    Easy Intergration
  • 3
    Customer Support
  • 1
    Integration to jira
CONS OF TESTRAIL
  • 4
    Pricey

related Testrail posts

Shared insights
on
TestrailTestrailmablmabl

Hello everyone!

Need your advice in my new company. I am new to this website as well. Any thoughts on what TCM we can use if we have mabl Automation to have not big total expenses? Or to change the automation framework and get TCM.

I used Testrail ($1-2k) as TCM but expenses are quite big in total with Mabl ($1k) . The product has lots of visual content such as diagrams, graphics, and tables where data displayed from 1 big table. Company is using Mabl for Automation. There are not so much Backend tests. Frontend is not covered and no started.

I am looking for TCM to start creating TCs for manual testing, then want to highlight tests for regression and automate them. Also team ready to automate Backend as well.

See more
Shared insights
on
Visual StudioVisual StudioTestrailTestrail

I have used Testrail for several years but my company is switching to Devops for everything (including QA/Testing). We are dropping TestRail because of the cost. TestRail is, overall, a better tool for QA. Devops is very tedious for test plan/suite/case creation. Actually executing a test is pretty good, But writing / creating the plans are pretty cumbersome. I have requested a few improvements through the Visual Studio community but I don't have high hopes. I just don't think enough QAs are using Devops. Is anybody else in this boat?

See more
BlazeMeter logo

BlazeMeter

67
155
13
The Load Testing Platform for Developers
67
155
+ 1
13
PROS OF BLAZEMETER
  • 10
    I can run load tests without needing JMeter scripts.
  • 3
    Easy to prepare JMeter workers
CONS OF BLAZEMETER
  • 1
    Costly
  • 1
    UI centric

related BlazeMeter posts

Shared insights
on
BlazeMeterBlazeMeterApache JMeterApache JMeter

How to optimize performance testing for services on AWS Cloud? Recently our organization application has been migrated to the cloud. And I'm wondering how to commence the performance testing. Currently, our team using Apache JMeter with BlazeMeter. However, they are facing some challenges while using them. So we are looking for new tools to overcome those challenges.

See more
Selenium logo

Selenium

15.4K
12.3K
525
Web Browser Automation
15.4K
12.3K
+ 1
525
PROS OF SELENIUM
  • 175
    Automates browsers
  • 154
    Testing
  • 101
    Essential tool for running test automation
  • 24
    Record-Playback
  • 24
    Remote Control
  • 8
    Data crawling
  • 7
    Supports end to end testing
  • 6
    Easy set up
  • 6
    Functional testing
  • 4
    The Most flexible monitoring system
  • 3
    End to End Testing
  • 3
    Easy to integrate with build tools
  • 2
    Comparing the performance selenium is faster than jasm
  • 2
    Record and playback
  • 2
    Compatible with Python
  • 2
    Easy to scale
  • 2
    Integration Tests
  • 0
    Integrated into Selenium-Jupiter framework
CONS OF SELENIUM
  • 8
    Flaky tests
  • 4
    Slow as needs to make browser (even with no gui)
  • 2
    Update browser drivers

related Selenium posts

Kamil Kowalski
Lead Architect at Fresha · | 28 upvotes · 3.9M views

When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.

See more
Benjamin Poon
QA Manager - Engineering at HBC Digital · | 8 upvotes · 1.9M views

For our digital QA organization to support a complex hybrid monolith/microservice architecture, our team took on the lofty goal of building out a commonized UI test automation framework. One of the primary requisites included a technical minimalist threshold such that an engineer or analyst with fundamental knowledge of JavaScript could automate their tests with greater ease. Just to list a few: - Nightwatchjs - Selenium - Cucumber - GitHub - Go.CD - Docker - ExpressJS - React - PostgreSQL

With this structure, we're able to combine the automation efforts of each team member into a centralized repository while also providing new relevant metrics to business owners.

See more
Postman logo

Postman

92.7K
79.5K
1.8K
Only complete API development environment
92.7K
79.5K
+ 1
1.8K
PROS OF POSTMAN
  • 490
    Easy to use
  • 369
    Great tool
  • 276
    Makes developing rest api's easy peasy
  • 156
    Easy setup, looks good
  • 144
    The best api workflow out there
  • 53
    It's the best
  • 53
    History feature
  • 44
    Adds real value to my workflow
  • 43
    Great interface that magically predicts your needs
  • 35
    The best in class app
  • 12
    Can save and share script
  • 10
    Fully featured without looking cluttered
  • 8
    Collections
  • 8
    Option to run scrips
  • 8
    Global/Environment Variables
  • 7
    Shareable Collections
  • 7
    Dead simple and useful. Excellent
  • 7
    Dark theme easy on the eyes
  • 6
    Awesome customer support
  • 6
    Great integration with newman
  • 5
    Documentation
  • 5
    Simple
  • 5
    The test script is useful
  • 4
    Saves responses
  • 4
    This has simplified my testing significantly
  • 4
    Makes testing API's as easy as 1,2,3
  • 4
    Easy as pie
  • 3
    API-network
  • 3
    I'd recommend it to everyone who works with apis
  • 3
    Mocking API calls with predefined response
  • 2
    Now supports GraphQL
  • 2
    Postman Runner CI Integration
  • 2
    Easy to setup, test and provides test storage
  • 2
    Continuous integration using newman
  • 2
    Pre-request Script and Test attributes are invaluable
  • 2
    Runner
  • 2
    Graph
  • 1
    <a href="http://fixbit.com/">useful tool</a>
CONS OF POSTMAN
  • 10
    Stores credentials in HTTP
  • 9
    Bloated features and UI
  • 8
    Cumbersome to switch authentication tokens
  • 7
    Poor GraphQL support
  • 5
    Expensive
  • 3
    Not free after 5 users
  • 3
    Can't prompt for per-request variables
  • 1
    Import swagger
  • 1
    Support websocket
  • 1
    Import curl

related Postman posts

Vaibhav Taunk
Team Lead at Technovert · | 31 upvotes · 3.9M views

I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.

See more
Noah Zoschke
Engineering Manager at Segment · | 30 upvotes · 2.9M views

We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. A public API is only as good as its #documentation. For the API reference doc we are using Postman.

Postman is an “API development environment”. You download the desktop app, and build API requests by URL and payload. Over time you can build up a set of requests and organize them into a “Postman Collection”. You can generalize a collection with “collection variables”. This allows you to parameterize things like username, password and workspace_name so a user can fill their own values in before making an API call. This makes it possible to use Postman for one-off API tasks instead of writing code.

Then you can add Markdown content to the entire collection, a folder of related methods, and/or every API method to explain how the APIs work. You can publish a collection and easily share it with a URL.

This turns Postman from a personal #API utility to full-blown public interactive API documentation. The result is a great looking web page with all the API calls, docs and sample requests and responses in one place. Check out the results here.

Postman’s powers don’t end here. You can automate Postman with “test scripts” and have it periodically run a collection scripts as “monitors”. We now have #QA around all the APIs in public docs to make sure they are always correct

Along the way we tried other techniques for documenting APIs like ReadMe.io or Swagger UI. These required a lot of effort to customize.

Writing and maintaining a Postman collection takes some work, but the resulting documentation site, interactivity and API testing tools are well worth it.

See more
Gatling logo

Gatling

248
317
21
Open-source load testing for DevOps and CI/CD
248
317
+ 1
21
PROS OF GATLING
  • 6
    Great detailed reports
  • 5
    Can run in cluster mode
  • 5
    Loadrunner
  • 3
    Scala based
  • 2
    Load test as code
  • 0
    Faster
CONS OF GATLING
  • 2
    Steep Learning Curve
  • 1
    Hard to test non-supported protocols
  • 0
    Not distributed

related Gatling posts

Shared insights
on
LocustLocustGatlingGatlingJenkinsJenkins

I am looking for a performance testing tool that I can use for testing the documents accessed by many users simultaneously. I also want to integrate Jenkins with the performance automation tool. I am not able to decide which shall I choose Gatling or Locust. But for me, Jenkins integration is important. I am looking for suggestions for this scenario.

See more
Vrashab Jian
Shared insights
on
Flood IOFlood IOLocustLocustGatlingGatling

I have to run a multi-user load test and have test scripts developed in Gatling and Locust.

I am planning to run the tests with Flood IO, as it allows us to create a custom grid. They support Gatling. Did anyone try Locust tests? I would prefer not to use multiple infra providers for running these tests!

See more
Locust logo

Locust

171
315
51
Define user behaviour with Python code, and swarm your system with millions of simultaneous users
171
315
+ 1
51
PROS OF LOCUST
  • 15
    Hackable
  • 11
    Supports distributed
  • 7
    Open source
  • 6
    Easy to use
  • 6
    Easy to setup
  • 4
    Fast
  • 2
    Test Anything
CONS OF LOCUST
  • 1
    Bad design

related Locust posts

Shared insights
on
LocustLocustGatlingGatlingJenkinsJenkins

I am looking for a performance testing tool that I can use for testing the documents accessed by many users simultaneously. I also want to integrate Jenkins with the performance automation tool. I am not able to decide which shall I choose Gatling or Locust. But for me, Jenkins integration is important. I am looking for suggestions for this scenario.

See more
Vrashab Jian
Shared insights
on
Flood IOFlood IOLocustLocustGatlingGatling

I have to run a multi-user load test and have test scripts developed in Gatling and Locust.

I am planning to run the tests with Flood IO, as it allows us to create a custom grid. They support Gatling. Did anyone try Locust tests? I would prefer not to use multiple infra providers for running these tests!

See more
JavaScript logo

JavaScript

351.2K
267.4K
8.1K
Lightweight, interpreted, object-oriented language with first-class functions
351.2K
267.4K
+ 1
8.1K
PROS OF JAVASCRIPT
  • 1.7K
    Can be used on frontend/backend
  • 1.5K
    It's everywhere
  • 1.2K
    Lots of great frameworks
  • 897
    Fast
  • 745
    Light weight
  • 425
    Flexible
  • 392
    You can't get a device today that doesn't run js
  • 286
    Non-blocking i/o
  • 237
    Ubiquitousness
  • 191
    Expressive
  • 55
    Extended functionality to web pages
  • 49
    Relatively easy language
  • 46
    Executed on the client side
  • 30
    Relatively fast to the end user
  • 25
    Pure Javascript
  • 21
    Functional programming
  • 15
    Async
  • 13
    Full-stack
  • 12
    Setup is easy
  • 12
    Future Language of The Web
  • 12
    Its everywhere
  • 11
    Because I love functions
  • 11
    JavaScript is the New PHP
  • 10
    Like it or not, JS is part of the web standard
  • 9
    Expansive community
  • 9
    Everyone use it
  • 9
    Can be used in backend, frontend and DB
  • 9
    Easy
  • 8
    Most Popular Language in the World
  • 8
    Powerful
  • 8
    Can be used both as frontend and backend as well
  • 8
    For the good parts
  • 8
    No need to use PHP
  • 8
    Easy to hire developers
  • 7
    Agile, packages simple to use
  • 7
    Love-hate relationship
  • 7
    Photoshop has 3 JS runtimes built in
  • 7
    Evolution of C
  • 7
    It's fun
  • 7
    Hard not to use
  • 7
    Versitile
  • 7
    Its fun and fast
  • 7
    Nice
  • 7
    Popularized Class-Less Architecture & Lambdas
  • 7
    Supports lambdas and closures
  • 6
    It let's me use Babel & Typescript
  • 6
    Can be used on frontend/backend/Mobile/create PRO Ui
  • 6
    1.6K Can be used on frontend/backend
  • 6
    Client side JS uses the visitors CPU to save Server Res
  • 6
    Easy to make something
  • 5
    Clojurescript
  • 5
    Promise relationship
  • 5
    Stockholm Syndrome
  • 5
    Function expressions are useful for callbacks
  • 5
    Scope manipulation
  • 5
    Everywhere
  • 5
    Client processing
  • 5
    What to add
  • 4
    Because it is so simple and lightweight
  • 4
    Only Programming language on browser
  • 1
    Test
  • 1
    Hard to learn
  • 1
    Test2
  • 1
    Not the best
  • 1
    Easy to understand
  • 1
    Subskill #4
  • 1
    Easy to learn
  • 0
    Hard 彤
CONS OF JAVASCRIPT
  • 22
    A constant moving target, too much churn
  • 20
    Horribly inconsistent
  • 15
    Javascript is the New PHP
  • 9
    No ability to monitor memory utilitization
  • 8
    Shows Zero output in case of ANY error
  • 7
    Thinks strange results are better than errors
  • 6
    Can be ugly
  • 3
    No GitHub
  • 2
    Slow

related JavaScript posts

Zach Holman

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

See more
Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 44 upvotes · 10.1M 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
Git logo

Git

290.1K
174.3K
6.6K
Fast, scalable, distributed revision control system
290.1K
174.3K
+ 1
6.6K
PROS OF GIT
  • 1.4K
    Distributed version control system
  • 1.1K
    Efficient branching and merging
  • 959
    Fast
  • 845
    Open source
  • 726
    Better than svn
  • 368
    Great command-line application
  • 306
    Simple
  • 291
    Free
  • 232
    Easy to use
  • 222
    Does not require server
  • 27
    Distributed
  • 22
    Small & Fast
  • 18
    Feature based workflow
  • 15
    Staging Area
  • 13
    Most wide-spread VSC
  • 11
    Role-based codelines
  • 11
    Disposable Experimentation
  • 7
    Frictionless Context Switching
  • 6
    Data Assurance
  • 5
    Efficient
  • 4
    Just awesome
  • 3
    Github integration
  • 3
    Easy branching and merging
  • 2
    Compatible
  • 2
    Flexible
  • 2
    Possible to lose history and commits
  • 1
    Rebase supported natively; reflog; access to plumbing
  • 1
    Light
  • 1
    Team Integration
  • 1
    Fast, scalable, distributed revision control system
  • 1
    Easy
  • 1
    Flexible, easy, Safe, and fast
  • 1
    CLI is great, but the GUI tools are awesome
  • 1
    It's what you do
  • 0
    Phinx
CONS OF GIT
  • 16
    Hard to learn
  • 11
    Inconsistent command line interface
  • 9
    Easy to lose uncommitted work
  • 7
    Worst documentation ever possibly made
  • 5
    Awful merge handling
  • 3
    Unexistent preventive security flows
  • 3
    Rebase hell
  • 2
    When --force is disabled, cannot rebase
  • 2
    Ironically even die-hard supporters screw up badly
  • 1
    Doesn't scale for big data

related Git posts

Simon Reymann
Senior Fullstack Developer at QUANTUSflow Software GmbH · | 30 upvotes · 9.3M 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
Tymoteusz Paul
Devops guy at X20X Development LTD · | 23 upvotes · 8.3M views

Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

See more