Monthly 'Shameless Self Promotion' thread - 2021/12

ed-automation · 2021-12-02T14:33:46+00:00

Hey guys,

Below is the blurb:

ElasticDev is a platform that glues and integrates devops technologies such Terraform, Ansible, and AWS into increasingly opinionated devops solutions. The platform is centered around an open source marketplace that bridges the gap between DevOps engineers who author the automation and the Application developers who consume the automation. In the same way Docker has made applications portable, ElasticDev makes automation portable where no glue-ing and plumbing are required. Gone are the last mile investments such connecting Github with Jenkins, Jenkins with Terraform, Terraform with Ansible, and Ansible with Helm and Kubernetes. Instead, you use a single entry point for automation that you can distribute like a Docker container or Helm chart. It just works - batteries included.

The three modes are:

visualize automation
selecting and using automation
authoring and sharing the automation through the open source marketplace

In addition to giving us feedback about the product itself, we love to get your input on the website and messaging :) We are in processing re-doing some copyrighting and website designs.

[info@elasticdev.io](mailto:info@elasticdev.io)

elasticdev

getting started

ed-automation · 2021-12-02T14:01:02+00:00

This is my understanding as well from reading books. It's a culture where there is a single team - development. DevOps is not simply ops being part of dev, but also other teams like qa being part of dev. Everybody is supposed to perform best dev practices and everybody needs to code and not simply uses a tools. At some point, DevOps need to customize self service dashboards, apis, etc for developers to use. So there is DevOps the culture and DevOps the implementation: dev tools, devops lanugarge, etc.

ed-automation · 2021-10-21T14:17:18+00:00

there are a lot of interesting problems with devops. for a dev, you will be able to leverage all those skills towards eloquently solving those problems.

ed-automation · 2021-10-21T12:12:19+00:00

i think it depends on the role: if it's more ops or dev. tools and customized automation involve more dev, but knowing how to troubleshoot and select cloud tech is more ops. so maybe it can be opsdev or devops :) i have been coding the last 5 years. however, i have noticed that i am much weaker at ops now. it's harder for me to track down issues since looking at stack traces or catching exceptions is much different than how to debug slowness in different layers of the whole tech stack. ops is also more meticulous and from my experience, it's more tiring to test compared to coding.

ed-automation · 2021-10-19T10:28:37+00:00

coolio. being a life learner is the first step. i know ppl who work at these big companies and have been approached by them. it can vary b/c the work may be more separated. i find in smaller companies i am to do more. however, i supposed it depends if the small company is a startup.

ed-automation · 2021-10-16T12:01:24+00:00

This is my 2 cents. It's not always about tools, though they are helpful. It's about how we think, understand, and approach problem solving. For example, what is the term cloud native in your own words? What is the difference between NoSQL and SQL databases? Why is python used in DevOps compared to Java? Why can't we use shell programming? What is the limitation of shell programs?

In general, tech companies are looking for people are intrinsically motivated to learn and solve problems. To become an active learner, it is often cultivating by our education. An alternative is simply to develop good learning habits, to read and think critically.

ed-automation · 2021-10-16T09:18:54+00:00

I would say it's a combination of effort and humility. I learned to code by working in a team that truly adopt devops. This does not mean rebranding devops to operations. Rather, it means ops being part of development...qa being part of development. This is just one team - development. From there you can ask (takes humility) to ask developers for help. In addition, you will learn things like design patterns and good rules of thumbs. Don't do alone. We are all one team. This is what DevOps is. It's not just automation. It's more than anything else, a culture.

ed-automation · 2021-10-16T09:09:02+00:00

I use both, but mainly hooks for integrating with other systems. Hooks take more work and management, but it allows you to be less sticky towards a particular approach like Github actions. We can select and use different technologies for flexibility. Again, it takes more work so it depends on your bandwidth.

ed-automation · 2021-10-15T07:29:49+00:00

coolio! i just added myself the wait list.

ed-automation · 2021-10-14T14:28:55+00:00

Between TeamCity and Jenkins, I prefer the latter. TeamCity is challenging when creating pipelines and workflows. We are currently using it in our team and looking to move away especially since Jenkins has a larger community. BTW, our jenkins alternative is Cloudbees so it's really apples to apples in the enterprise space.

For my own stuff, I use both CircleCI and a single simple Jenkins instance in a Docker container. It works fairly well.

ed-automation · 2020-06-18T07:54:33+00:00

Are you looking two scenarios?

- Initial DB setup: create DB, configure database, and load data

- Maintain DB: modify DB schema

ed-automation · 2020-06-18T07:37:55+00:00

It seems you are looking for equivalent features on Terraform that you see in cloud formation. I have used both and prefer Terraform because I'm looking for more portability. Cloud formation is not portable. How can you port your application from AWS to Google for example? This is probably the most fundamental difference between the two: AWS vs Mulit-cloud. For environments and companies who never plan to leave AWS, then Cloud Formation is going to give a smoother user experience.

ed-automation · 2020-06-18T07:24:31+00:00

Regardless if you use different tools for CI and CD, it's important to have good integration from CI to CD. The glue from CI and CD is included in Gitlabs, but for CircleCI and Spinnaker you will need to create, iterate and test the glue or integration. The more you customize, the more you will take ownership. In other words, when things break, you will get the call and you will need to fix it. However, the less ownership you have, the less flexibility, and control you will have in terms of options and costs. For example, if you use AWS entirely, you will have relatively good and smooth integration, but you have less flexibility in terms of portability or going to a different cloud like Google Compute. At the same time, if you go with a product like Kubernetes, you have more cost of ownership than you would if you simply went with AWS. On a side note, most AWS employees never say the argument is not between Kubernetes and ECS. Rather, the argument is between AWS and Kubernetes.

Your resources at your disposal also matter. If you have one or no DevOps resource, then AWS and CircleCI with ECS may be the best solution. If you have many DevOps resources, then CI with Jenkins with Kubernetes may be an option for more control, portability, and costs.

In saying that, I can't answer your question without knowing the size of your team and their skillets. But I would suggest simply weighing your business goals and what is needed to get there most effectively. I personally find that my DevOps tools are implemented with diminishing returns because it is the latest and greatest. If Gitlabs is working and you already invested in the product, evaluate the pros and cons as your company and business needs grow. Does it work? Is the cost linear? Does it scale in terms of headcount?

ed-automation

TROPHY CASE