Wouldn’t it be great if we would not need to define infrastructure but let applications themselves figure out what to do, where to run, and how to do all that? Klotho enables us to write Cloud-native microservices and applications and auto-magically get infrastructure and the code that ties it all together.
Continue readingDapr simplifies microservice communication through direct or event-based pub/sub messaging and helps us develop resilient and secured microservices. It performs service discovery, message broker integration, encryption, observability, secret management, and many other tasks. In this video, we are focusing on pub/sub events.
Continue readingHow should we design communication between microservices? Should it be synchronous or asynchronous? Should it be direct or through message brokers, event bussed, and gateways?
Continue readingHow do we develop microservices knowing that we cannot run the whole system locally? How do we connect local applications with microservices running in remote Kubernetes clusters? Can CodeZero be the solution?
Continue readingWhat are microservices architecture? Why do we use microservices? How do microservices talk to each other? How do we test microservices? What are the problems with microservices?
Continue readingDevOps is the word of the year. Everyone speaks about it, and many are hoping to apply it, even though most are confused what it truly means.
Inquiring about DevOps does not seem to help. If you speak with a software vendor, he’ll tell you that all you need to become DevOps ninja is to purchase his product. Puppet, Chef, Ansible, Docker, Terraform, Packer, Jenkins, Nexus, Git… Every software vendor seems to have a DevOps sticker attached to his product. You’ll notice those stickers being right next to “we make Docker easy” and “we convert your architecture into microservices.”
Continue reading
Today is an exciting day for me. I just decided that the book I spent the last eight months writing is ready for general public.
What made me write the book? Certainly not the promise of wealth since, as any author of technical books will confirm, there is no money that can compensate the number of hours involved in writing a technical book. The reasons behind this endeavor are of a different nature. I realized that this blog is a great way for me to explore different subjects and share my experience with the community. However, due to the format, blog posts do not give enough space to explore, in more details, subjects I’m passionate about so, around eight months ago, I decided to start working on The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices book. It treats similar subjects as those I write about in this blog, but with much more details. More importantly, the book allowed me to organize my experience into a much more coherent story.
The book is about different techniques that help us architect software in a better and more efficient way with microservices packed as immutable containers, tested and deployed continuously to servers that are automatically provisioned with configuration management tools. It’s about fast, reliable and continuous deployments with zero-downtime and ability to roll-back. It’s about scaling to any number of servers, designing self-healing systems capable of recuperation from both hardware and software failures and about centralized logging and monitoring of the cluster.
In other words, this book envelops the whole microservices development and deployment lifecycle using some of the latest and greatest practices and tools. We’ll use Docker, Kubernetes, Ansible, Ubuntu, Docker Swarm and Docker Compose, Consul, etcd, Registrator, confd, Jenkins, and so on. We’ll go through many practices and, even more, tools.
At this moment, around 70% is finished and you’ll receive regular updates if you decide to purchase the book. The truth is that my motivation for writing the book is the same as with this blog. I like sharing my experience and this book is one more way to accomplish that. You can set your own price and if you feel that the minimum amount is still too high, please send me a private message and I’ll get back to you with a free copy.
Please give The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices a try and let me know what you think. Any feedback is welcome and appreciated.
I worked with many different clients. From small greenfield projects all the way to big ones in sectors like automotive, lottery, banking, insurance and other industries. With few exceptions teams in those projects can be divided into those that started anew and think that they are using latest and greatest ways to develop and those that are in charge of bigger projects that started long time ago. The later group tends to put to much energy trying to stay afloat that latest and greatest is very low on their list of priorities.
Continue reading
In the previous article we developed our second Polymer Web Component. With two of them functionally finished, we’ll apply styles and create a way for users of our components to have partial control of the look and feel. Once that is done, we’ll improve our Demo page and create proper communication between our components.
Microservices are becoming more and more popular and many are choosing to transition away from monolithic architecture. However, this approach was mostly limited to back-end services. While it made a lot of sense to split them into smaller independent pieces that can be accessed only through their APIs, same did not apply to front-end. Why is that? I think that the answer lies in technologies we’re using. The way we are developing front-end is not designed to be split into smaller pieces.
Server-side rendering is becoming history. While enterprise might not agree with that statement and continues pushing for server-side frameworks that “magically” transform, for example, Java objects to HTML and JavaScript, client frameworks will continue to increase in popularity slowly sending server-side page rendering into oblivion. That leaves us with client-side frameworks. Single-Page Applications are what we tend to use today. AngularJS, React, ExtJS, ember.js and others proved to be a next step in evolution of front-end development. However, Single-Page Applications or not, most of them are promoting monolithic approach to front-end architecture.
Technology Conversations 