Alternatives to OpenLayers logo

Alternatives to OpenLayers

Leaflet, Google Maps, Mapbox, OpenStreetMap, and Cesium are the most popular alternatives and competitors to OpenLayers.
577
458
+ 1
57

What is OpenLayers and what are its top alternatives?

OpenLayers is a robust open-source web mapping library that allows users to display dynamic and interactive maps in web applications. Its key features include support for various data formats, integration with popular mapping services like Google Maps and OpenStreetMap, customizable styling options, and support for various interactions like zooming and panning. However, it can be complex for beginners to set up and lacks some advanced features compared to other mapping libraries.

  1. Leaflet: Leaflet is a lightweight and easy-to-use open-source mapping library that offers similar functionalities to OpenLayers. It provides support for multiple tile providers, customizable markers and popups, and a responsive design. Pros include its simplicity and ease of use, while cons include fewer advanced features compared to OpenLayers.
  2. Mapbox GL JS: Mapbox GL JS is a powerful mapping library that focuses on rendering vector maps with advanced styling capabilities, interactivity, and performance. It allows for creating custom maps with data-driven styling and supports 3D extrusions. Pros include its advanced styling options and performance, while cons include a steeper learning curve compared to OpenLayers.
  3. Google Maps JavaScript API: Google Maps API is a popular mapping solution that offers extensive features for embedding Google Maps in web applications. It provides functionalities like geocoding, directions, and Street View integration. Pros include the extensive documentation and features offered by Google Maps, while cons include potential limitations on free usage and dependency on Google's mapping services.
  4. HERE Maps API: HERE Maps API is a mapping platform that offers features like geocoding, routing, and custom map styling. It provides detailed map data and various SDKs for different platforms. Pros include detailed map data and route information, while cons include potential costs for advanced features and services.
  5. CesiumJS: CesiumJS is a 3D mapping library that focuses on globe visualization and geospatial data rendering. It supports 3D terrain, imagery, and vector data, making it suitable for advanced geospatial applications. Pros include its support for 3D visualization and performance, while cons include a specialized focus on 3D mapping compared to OpenLayers.
  6. ArcGIS API for JavaScript: ArcGIS API for JavaScript is a mapping library provided by Esri that offers advanced GIS functionalities like geoprocessing, spatial analysis, and offline mapping capabilities. It integrates seamlessly with Esri's ArcGIS platform and services. Pros include advanced GIS capabilities and integration with ArcGIS products, while cons include potential costs and complexity for beginners.
  7. MapTiler: MapTiler is a mapping platform that offers tile hosting, map styling, and integration with various mapping frameworks. It supports custom map designs, vector tiles, and geocoding services. Pros include its simplicity and support for custom map styling, while cons include potential costs for hosting and data services.
  8. GeoServer: GeoServer is an open-source server-side software that allows users to share and publish geospatial data and serve it as web services. It supports various data formats, styling options, and data projections. Pros include its flexibility and compatibility with different data sources, while cons include the need for server setup and maintenance compared to client-side mapping libraries like OpenLayers.
  9. Tangram: Tangram is a 2D and 3D mapping engine that focuses on rendering vector maps with custom styling and interactivity. It offers support for custom shaders, data-driven styling, and integration with various data sources. Pros include its flexibility and customizability, while cons include a learning curve for advanced styling and rendering techniques.
  10. Uber H3: Uber H3 is a geospatial indexing system that divides the world into hexagons for efficient spatial indexing and querying. It provides support for hierarchical geospatial data analysis and visualization, suitable for location-based services and analytics. Pros include its efficient indexing and querying capabilities, while cons include a specialized focus on geospatial data indexing compared to full-fledged mapping libraries like OpenLayers.

Top Alternatives to OpenLayers

  • Leaflet
    Leaflet

    Leaflet is an open source JavaScript library for mobile-friendly interactive maps. It is developed by Vladimir Agafonkin of MapBox with a team of dedicated contributors. Weighing just about 30 KB of gzipped JS code, it has all the features most developers ever need for online maps. ...

  • Google Maps
    Google Maps

    Create rich applications and stunning visualisations of your data, leveraging the comprehensiveness, accuracy, and usability of Google Maps and a modern web platform that scales as you grow. ...

  • Mapbox
    Mapbox

    We make it possible to pin travel spots on Pinterest, find restaurants on Foursquare, and visualize data on GitHub. ...

  • OpenStreetMap
    OpenStreetMap

    OpenStreetMap is built by a community of mappers that contribute and maintain data about roads, trails, cafés, railway stations, and much more, all over the world. ...

  • Cesium
    Cesium

    it is used to create the leading web-based globe and map for visualizing dynamic data. We strive for the best possible performance, precision, visual quality, ease of use, platform support, and content. ...

  • ArcGIS
    ArcGIS

    It is a geographic information system for working with maps and geographic information. It is used for creating and using maps, compiling geographic data, analyzing mapped information, sharing and much more. ...

  • 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. ...

OpenLayers alternatives & related posts

Leaflet logo

Leaflet

1.4K
1.1K
108
JavaScript library for mobile-friendly interactive maps
1.4K
1.1K
+ 1
108
PROS OF LEAFLET
  • 33
    Light weight
  • 28
    Free
  • 12
    Evolutive via plugins
  • 10
    OpenStreetMap
  • 9
    Strong community
  • 7
    Choice of map providers
  • 6
    Easy API
  • 3
    Alternative to Google Maps
CONS OF LEAFLET
    Be the first to leave a con

    related Leaflet posts

    Which will give a better map (better view, markers options, info window) in an Android OS app?

    Leaflet with Mapbox or Leaflet with OpenStreetMap?

    See more
    Google Maps logo

    Google Maps

    40.7K
    28.3K
    566
    Build highly customisable maps with your own content and imagery
    40.7K
    28.3K
    + 1
    566
    PROS OF GOOGLE MAPS
    • 253
      Free
    • 136
      Address input through maps api
    • 81
      Sharable Directions
    • 47
      Google Earth
    • 46
      Unique
    • 3
      Custom maps designing
    CONS OF GOOGLE MAPS
    • 4
      Google Attributions and logo
    • 1
      Only map allowed alongside google place autocomplete

    related Google Maps posts

    Francisco Quintero
    Tech Lead at Dev As Pros · | 13 upvotes · 1.6M views

    For Etom, a side project. We wanted to test an idea for a future and bigger project.

    What Etom does is searching places. Right now, it leverages the Google Maps API. For that, we found a React component that makes this integration easy because using Google Maps API is not possible via normal API requests.

    You kind of need a map to work as a proxy between the software and Google Maps API.

    We hate configuration(coming from Rails world) so also decided to use Create React App because setting up a React app, with all the toys, it's a hard job.

    Thanks to all the people behind Create React App it's easier to start any React application.

    We also chose a module called Reactstrap which is Bootstrap UI in React components.

    An important thing in this side project(and in the bigger project plan) is to measure visitor through out the app. For that we researched and found that Keen was a good choice(very good free tier limits) and also it is very simple to setup and real simple to send data to

    Slack and Trello are our defaults tools to comunicate ideas and discuss topics, so, no brainer using them as well for this project.

    See more
    Tom Klein

    Google Analytics is a great tool to analyze your traffic. To debug our software and ask questions, we love to use Postman and Stack Overflow. Google Drive helps our team to share documents. We're able to build our great products through the APIs by Google Maps, CloudFlare, Stripe, PayPal, Twilio, Let's Encrypt, and TensorFlow.

    See more
    Mapbox logo

    Mapbox

    708
    931
    112
    Design and publish beautiful maps
    708
    931
    + 1
    112
    PROS OF MAPBOX
    • 28
      Best mapping service outside of Google Maps
    • 22
      OpenStreetMap
    • 15
      Beautifully vectorable
    • 11
      Fluid user experience
    • 8
      Extensible
    • 7
      React/ RNative integration
    • 5
      3D Layers
    • 4
      Low Level API
    • 4
      Affordable
    • 3
      Great customer support
    • 3
      Custom themes
    • 2
      High data volume rendering
    CONS OF MAPBOX
      Be the first to leave a con

      related Mapbox posts

      Stephen Gheysens
      Lead Solutions Engineer at Inscribe · | 7 upvotes · 459.7K views

      Google Maps lets "property owners and their authorized representatives" upload indoor maps, but this appears to lack navigation ("wayfinding").

      MappedIn is a platform and has SDKs for building indoor mapping experiences (https://www.mappedin.com/) and ESRI ArcGIS also offers some indoor mapping tools (https://www.esri.com/en-us/arcgis/indoor-gis/overview). Finally, there used to be a company called LocusLabs that is now a part of Atrius and they were often integrated into airlines' apps to provide airport maps with wayfinding (https://atrius.com/solutions/personal-experiences/personal-wayfinder/).

      I previously worked at Mapbox and while I believe that it's a great platform for building map-based experiences, they don't have any simple solutions for indoor wayfinding. If I were doing this for fun as a side-project and prioritized saving money over saving time, here is what I would do:

      • Create a graph-based dataset representing the walking paths around your university, where nodes/vertexes represent the intersections of paths, and edges represent paths (literally paths outside, hallways, short path segments that represent entering rooms). You could store this in a hosted graph-based database like Neo4j, Amazon Neptune , or Azure Cosmos DB (with its Gremlin API) and use built-in "shortest path" queries, or deploy a PostgreSQL service with pgRouting.

      • Add two properties to each edge: one property for the distance between its nodes (libraries like @turf/helpers will have a distance function if you have the latitude & longitude of each node), and another property estimating the walking time (based on the distance). Once you have these values saved in a graph-based format, you should be able to easily query and find the data representation of paths between two points.

      • At this point, you'd have the routing problem solved and it would come down to building a UI. Mapbox arguably leads the industry in developer tools for custom map experiences. You could convert your nodes/edges to GeoJSON, then either upload to Mapbox and create a Tileset to visualize the paths, or add the GeoJSON to the map on the fly.

      *You might be able to use open source routing tools like OSRM (https://github.com/Project-OSRM/osrm-backend/issues/6257) or Graphhopper (instead of a custom graph database implementation), but it would likely be more involved to maintain these services.

      See more

      Which will give a better map (better view, markers options, info window) in an Android OS app?

      Leaflet with Mapbox or Leaflet with OpenStreetMap?

      See more
      OpenStreetMap logo

      OpenStreetMap

      250
      466
      56
      The free editable map of the whole world
      250
      466
      + 1
      56
      PROS OF OPENSTREETMAP
      • 22
        Simple
      • 17
        Free
      • 9
        Open-Source
      • 7
        Open-Data
      • 1
        React/ RNative integration
      CONS OF OPENSTREETMAP
        Be the first to leave a con

        related OpenStreetMap posts

        Adam Abdelmoula
        CPO at Split Mobile Software · | 5 upvotes · 476.3K views

        We need some advice about the map services provider. We are a mobility app that just launched 5 months ago in Tunisia offering P2P carpooling. We are currently using Google Maps API for maps (Places API, Geocoding API, Directions API & Distance Matrix API). Thus, we received expensive bills from Google Cloud following the number of requests we are using. We are looking forward to reduce the number of requests in general because we can't afford these large bills at this stage, knowing that they are going to increase proportionally to the active users of the app. We tried to optimize multiple times but it isn't enough. We are searching for optimization advice or ideas on how we use the APIs, or other map providers (like OpenStreetMap or similar) that offers free or cheaper options than Google Maps, without lacking quality of information (we are in Tunisia and we have to choose options that have enough data about Tunisia). Thanks!

        See more

        Which will give a better map (better view, markers options, info window) in an Android OS app?

        Leaflet with Mapbox or Leaflet with OpenStreetMap?

        See more
        Cesium logo

        Cesium

        51
        105
        1
        A javascript library to build 3D globes and 2D maps
        51
        105
        + 1
        1
        PROS OF CESIUM
        • 1
          Fully interactive 3D and can dynamically switch to 2D.
        CONS OF CESIUM
          Be the first to leave a con

          related Cesium posts

          ArcGIS logo

          ArcGIS

          133
          184
          20
          A geographic information system for working with maps
          133
          184
          + 1
          20
          PROS OF ARCGIS
          • 7
            Reponsive
          • 4
            A lot of widgets
          • 4
            Data driven vizualisation
          • 2
            Easy tà learn
          • 2
            3D
          • 1
            Easy API
          CONS OF ARCGIS
            Be the first to leave a con

            related ArcGIS posts

            Stephen Gheysens
            Lead Solutions Engineer at Inscribe · | 7 upvotes · 459.7K views

            Google Maps lets "property owners and their authorized representatives" upload indoor maps, but this appears to lack navigation ("wayfinding").

            MappedIn is a platform and has SDKs for building indoor mapping experiences (https://www.mappedin.com/) and ESRI ArcGIS also offers some indoor mapping tools (https://www.esri.com/en-us/arcgis/indoor-gis/overview). Finally, there used to be a company called LocusLabs that is now a part of Atrius and they were often integrated into airlines' apps to provide airport maps with wayfinding (https://atrius.com/solutions/personal-experiences/personal-wayfinder/).

            I previously worked at Mapbox and while I believe that it's a great platform for building map-based experiences, they don't have any simple solutions for indoor wayfinding. If I were doing this for fun as a side-project and prioritized saving money over saving time, here is what I would do:

            • Create a graph-based dataset representing the walking paths around your university, where nodes/vertexes represent the intersections of paths, and edges represent paths (literally paths outside, hallways, short path segments that represent entering rooms). You could store this in a hosted graph-based database like Neo4j, Amazon Neptune , or Azure Cosmos DB (with its Gremlin API) and use built-in "shortest path" queries, or deploy a PostgreSQL service with pgRouting.

            • Add two properties to each edge: one property for the distance between its nodes (libraries like @turf/helpers will have a distance function if you have the latitude & longitude of each node), and another property estimating the walking time (based on the distance). Once you have these values saved in a graph-based format, you should be able to easily query and find the data representation of paths between two points.

            • At this point, you'd have the routing problem solved and it would come down to building a UI. Mapbox arguably leads the industry in developer tools for custom map experiences. You could convert your nodes/edges to GeoJSON, then either upload to Mapbox and create a Tileset to visualize the paths, or add the GeoJSON to the map on the fly.

            *You might be able to use open source routing tools like OSRM (https://github.com/Project-OSRM/osrm-backend/issues/6257) or Graphhopper (instead of a custom graph database implementation), but it would likely be more involved to maintain these services.

            See more
            JavaScript logo

            JavaScript

            351.3K
            267.5K
            8.1K
            Lightweight, interpreted, object-oriented language with first-class functions
            351.3K
            267.5K
            + 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.2K
            174.4K
            6.6K
            Fast, scalable, distributed revision control system
            290.2K
            174.4K
            + 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