TrustRadius
Hive Mind Your FrontendWe are using Swarm for our analytics gathering service. Using swarm allows for quick workload scaling and using less hardware than was needed before.,Creating complex containers using docker files which automate a lot of DevOps manual labor Having some preconfigured containers to do fast tests The swarm takes away a lot of the work you would need to do for high availability,Kitematic UI is still very limited in functionality Containers on Windows are somewhat hit and miss, Linux is strongly recommended Swarm interface is mostly command line Some network limitations (like remote client IP passthrough),10,With Swarm we managed to have the horizontal network bandwidth scale to gather data from clients on slow internet connections A minor negative is that you always need at least 3 nodes for redundancy, which makes it less ideal for quick proof of concept type scenarios.,,Visual Studio IDE, NetBeans, Ubuntu Linux, CentOS, Eclipse,20,2,lightweight scalable services that require a lot of concurrent access load balancing high availability devops,10,Yes,Product Features Product Usability,If I had more time, I would have tried Kubernetes as well.,Scale the number of replicas Template a service Install the service,tagging the containers takes some getting use to some networking details are hard to configure (like remote client IP passthrough) some service manipulation commands have bad defaults (like changing an image but not using the authentication needed to pullit by default),No,8Docker Swarm - feature rich, simple to maintainWe currently have an array of microservices, and faas, spread out, and deployed in different instances of our servers, all of which have the benefit of Docker containers. We are currently taking advantage of the Docker Swarm concept for maintaining our decentralized infrastructure, as well as our data, in order to seamlessly keep the cohesion among the data services, as well as for making our up/down scaling process easier to achieve.,Up and Down scaling of decentralized microservice instances Remote maintenance and deployment of the existing docker based services Smallest possible down time of our services upon the necessity of deployment, and maintenance routines,Simpler diagnostics: Today, with both Docker and Swarm, although it offers all the necessary diagnostics tools, as well as infos. The task of taking down one failing service, which in turn has failed due to some problem with some specific container, image, or network, seems a little bit of overhead. One needs to go all the way down the chain, find find by name or ID, until we get to the root of the problem. I think we could use a more 'intuitive' way of reaching the real cause of the problem, without the need to have to go through such a big stack of different commands. Monitoring and logging tools: this one can arguably go together with the previously mentioned diagnostics 'issue'. Today, one can only find third party diagnostic, and monitoring tools. Sometimes, with the lack of a good indication, one has to go with lower-than-optimal tools whereby the job of logging and monitoring can be achieved. Better, or more pervasive community, with some more in-depth whitepapers, documentation, or tutorials. Sometimes it's a little hard to come up with the solution for a particular requirement, for the lack of more in-depth documentation out there. Also, it's still discussed in some communities that Swarm is not yet 100% ready for business critical solutions. I think this kind of opinion/fear could be better dismissed, if more substantial documentation support could have been provided.,10,Faster Deployment: we have achieved a full deployment cycle with a substantially lower time by using docker swarm concepts. Which in turn has rendered a significant improvement on our crisis management, down time, and maintenance routines. Down time servers is now a thing of the past, and our customers have grown to trust our 'release days' a lot more. Docker swarm has played a beautiful role when partnering its tools with our infrastructure as a code policies. Having a brand new service, or an entire solution spawned, as well as up/down scaling our already existing ones, have become a breeze. Our sales team are more confident now, since our 'ready for usage' window has shrank down substantially. Hard to find skilled DevOps professionals: with the adoption of docker Swarm, we have added an extra level of difficulty by finding the right professionals that can be hands-on with our solutions, since it's a fairly new technology, as well as it requires a somewhat steep learning curve.,Kubernetes,Kubernetes
Unspecified
Swarm
5 Ratings
Score 9.5 out of 101
<a href='https://www.trustradius.com/static/about-trustradius-scoring' target='_blank' rel='nofollow'>trScore algorithm: Learn more.</a>TRScore

Swarm Reviews

Swarm
5 Ratings
<a href='https://www.trustradius.com/static/about-trustradius-scoring' target='_blank' rel='nofollow'>trScore algorithm: Learn more.</a>
Score 9.5 out of 101
Show Filters 
Hide Filters 
Filter 5 vetted Swarm reviews and ratings
Clear all filters
Overall Rating
Reviewer's Company Size
Last Updated
By Topic
Industry
Department
Experience
Job Type
Role
Reviews (1-2 of 2)
  Vendors can't alter or remove reviews. Here's why.
Vlad VARNA profile photo
March 23, 2018

Swarm Review: "Hive Mind Your Frontend"

Score 10 out of 10
Vetted Review
Verified User
Review Source
We are using Swarm for our analytics gathering service. Using swarm allows for quick workload scaling and using less hardware than was needed before.
  • Creating complex containers using docker files which automate a lot of DevOps manual labor
  • Having some preconfigured containers to do fast tests
  • The swarm takes away a lot of the work you would need to do for high availability
  • Kitematic UI is still very limited in functionality
  • Containers on Windows are somewhat hit and miss, Linux is strongly recommended
  • Swarm interface is mostly command line
  • Some network limitations (like remote client IP passthrough)
Great for light frontends and (REST) microservices that don't depend on hardware/drivers and just do DB/file IO. Not so great for dev virtual machines and testing complex network configurations.
Read Vlad VARNA's full review
Claudio Fernando Maciel profile photo
March 06, 2018

Review: "Docker Swarm - feature rich, simple to maintain"

Score 10 out of 10
Vetted Review
Verified User
Review Source
We currently have an array of microservices, and faas, spread out, and deployed in different instances of our servers, all of which have the benefit of Docker containers. We are currently taking advantage of the Docker Swarm concept for maintaining our decentralized infrastructure, as well as our data, in order to seamlessly keep the cohesion among the data services, as well as for making our up/down scaling process easier to achieve.
  • Up and Down scaling of decentralized microservice instances
  • Remote maintenance and deployment of the existing docker based services
  • Smallest possible down time of our services upon the necessity of deployment, and maintenance routines
  • Simpler diagnostics: Today, with both Docker and Swarm, although it offers all the necessary diagnostics tools, as well as infos. The task of taking down one failing service, which in turn has failed due to some problem with some specific container, image, or network, seems a little bit of overhead. One needs to go all the way down the chain, find find by name or ID, until we get to the root of the problem. I think we could use a more 'intuitive' way of reaching the real cause of the problem, without the need to have to go through such a big stack of different commands.
  • Monitoring and logging tools: this one can arguably go together with the previously mentioned diagnostics 'issue'. Today, one can only find third party diagnostic, and monitoring tools. Sometimes, with the lack of a good indication, one has to go with lower-than-optimal tools whereby the job of logging and monitoring can be achieved.
  • Better, or more pervasive community, with some more in-depth whitepapers, documentation, or tutorials. Sometimes it's a little hard to come up with the solution for a particular requirement, for the lack of more in-depth documentation out there. Also, it's still discussed in some communities that Swarm is not yet 100% ready for business critical solutions. I think this kind of opinion/fear could be better dismissed, if more substantial documentation support could have been provided.
Microservices and FAAS continuous Integration is the keyword which comes to my mind when I think of the best reason why someone should use Swarm in one's project. The ease of having one's solution deployed is basically a no brainer by having at one's disposal the stack deployment tools.

Small solutions, where there the necessity of having a decentralized architecture does not come to play, in my opinion, would not take full advantage of using Docker in Swarm mode, since with the extra stack also comes the necessity of an extra amount of proficiency to both come up with, and maintain such an infrastructure.
Read Claudio Fernando Maciel's full review

About Swarm

Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual Docker host. 
Categories:  Container Management

Swarm Technical Details

Operating Systems: Unspecified
Mobile Application:No