The code is the key to determine if your company will be another level of Infrastructure management and automation. This has never so been clear as the last in recent years.
The number of opportunities for professionals like DevOps, SRE, or an Infrastructure Engineer in some markets exceeds the demand for Software Engineers.
Sounds that the tools that have been used successfully for a while seem to no longer serve teams and companies.
Nowadays, with the high demand for hybrid cloud, and even for companies that choose a unique cloud provider are failing. The tools didn’t provide support for containers, passing through virtual machines, and covering other services that want adopting best practices.
Faced with this scenario, many looked at Terraform as a tool that has achieved considerable success in provisioning infrastructure in different cloud providers as the final solution for all issues.
However, innovation is hardly made up of sudden jumps as many would like to tell. …
I’m an engineer that worked with infrastructure as a system engineer at that time when we didn’t know what’s Jenkins because it was called Hudson. When NGNIX had a logo that looks like a Russian jet.
I was reflecting on which options we have to run Kubernetes locally in my macOS. I know that on Linux the options are much more flexible because Linux is the Kubernetes home.
Unfortunately, I have to work with macOS as most of the Engineers that I have contact with. Looking for attending my requirement I made an analysis of Docker Desktop, Minikube, and Kind to understand what is the best option to run my Kubernetes Cluster.
Some Bluetooth devices, especially proprietary devices, did not work properly on old versions of Fedora other than this latest version, due to the great improvements coming from the low level and from the user level showing a more stable support.
I believe that much of this effort comes from the impressive community that Fedora has. This shows how the distribution can focus on innovation and at the same time stabilize resources requested by users.
In my environment has a “Lenovo ThinkPad T460p” laptop where I use daily the bluetooth devices “Logitech Keyboard Model K810” and “Beats Studio Wireless Model B0501”.
I am running the version 27 of Fedora with all the updated packages. At this point I have the “4.14.13–300.fc27.x86_64” …
A normal day I was under the protection of my headphones thinking about some ideas like kubernetes clusters, continuous integration, continuous deployment was when I received the mission: We could migrate to Google DNS!
Almost instantly I started thinking about my requirements for this migration:
* Create an Infrastructure as a code
* Document all zones and records
* Easy reproducibility
With my requirements in the mind I thought: I need create a tool to make this communication between my DNS data and Google DNS.
That’s when I looked at the Google DNS API documentation and realized that Python 3 was supported by the libraries that allowed this connection, this can be a lot of fun. I began to think about how tedious it was to read configuration files from the zones and how terrible that would be for an API communication. The data structure is one of the subjects that I never tire of studying.
Solutions such as NoSQL database have shown us the power that a JSON file with a simple key and value can have in storing and fetching data.
So I came up with the idea to solve the first two requirements of my mission: I can create the provisioning to Google DNS using the API. I can along with zones files have a versioning documented about what that was provisioned. …
I remember glorious times, in the year 1998. Where I and some colleagues set up a Sun Microsystems(Sparc) server to serve as a DNS using Debian. Everything was complicated and as new engineers did not give up knowing every piece of the server, how they worked, it was practically the era of caves in terms of data centers.
Today we have a many of new concepts, technologies and an increasingly faster. Where those who do not move quickly towards the new one may not need to move anymore. …
I am not an entrepreneur or a high-level manager, but in the eyes of an engineer I would like to share some insides.
Many should be thinking programming languages or specific technologies will be the theme of this post. I hope I do not disappoint my fellows, but definitely this does not seem to have relevance in the history of impressive projects. Who would have spoken a few years ago that PHP could be the difference for Facebook or Python as the engine of YouTube. These examples constantly surprise us, I speak of us engineers who defend programming languages, technologies and methodologies with great persuasion. If technologies were not determinant in the success or failure, what characteristics drive success?
Modestly I believe in the good old advisor: move quickly and run with quality.
Moving quickly is definitely one of the most complex features for large companies, making any group of young engineers a powerful competitor.
Performing with a focus on quality has always been an opinion about who evaluates, but numbers often say more than criticism. …