I put together a quick introduction to my Java colleagues into Golang to make some appetite to try it out. This presentation is the first in the series of Microservice development with Golang and focusing on the language elements sprinkled with example code links. It tries to compare them with Java to help the easier understanding, why Go has a potential in enterprise environment even in private/hybrid or private cloud scenarios with low resource usage and efficient concurrency.
-=CodeventoR=-
Anything, but enterprise :)
Monday, August 8, 2016
Golang basics for Java developers
Tuesday, May 3, 2016
Microservices: just a trend or real evolution?
Today
I had a discussion with my colleague about the necessary coding style
changes in microservice development. In my opinion we should revise
our practices for simplifications, because we socialized on code
reusability in monoliths and these new kids on the block are playing
differently. At the end of the discussion he asked a question from
me:
“Is the microservice architecture is a trend or evolution?
Microservice
benefits
Lot of pages listing why do we need microservices
and writing long-long lists about their magical nature, but I think
it has two main reasons: scalability and development time.
In some blog post the list has more items like:
resilience(no, just restarts faster...)- easy to enhance (I said the same with development time)
ease of deployment (Bahhh. Releasing and integrating 50-100 microservices couldn't be easier then releasing a single monolith, but different...)Single Responsibility(yeah, serve the business logic, provide proper logging and incident handling, integrate with other services, deliver KPI metrics, being resilient, etc...– hahaha....)Low impact on other services(due the the SRP in the previous point, I have doubts about how low is the impact when others are depending on it...)- etc...
Labels:
coding style,
microservices,
moore's law,
scalability
Wednesday, September 16, 2015
Changes of Dockery 0.3.0
Huh! Finally Dockery version 0.3.0 is ready to get released and I already published the hosted version. The Chrome update scheduled to this week. It took some time release a new version, because of my holidays and flu, but the real reason was the scope of the release was too big.
Because of the efficient mixture of my ego and terrible estimation skills :)
Let's see what's changed and why:
- search for container diff - the simple paging is not so efficient, I had to go through long list of changes sometimes to find what I'm looking for.
- commit container as image - initial version, I don't know this feature how often used. Personally I prefer creating Dockerfiles. It will be improved with some extra features (Dockerfile statement filtering, etc.)
- extending saved configuration data - from now some extra stuff will be saved too. I'd like to implement to reenter to the last state of the app at the next run.
- bootstrapping page - a nice eye-candy to hide angular placeholders during the app loading :)
- login into the docker hub - to push docker image (will be implemented in 0.3.1) back to a repo we need to login
- cosmetics - removed $promise from json data, added some details how to setup CORS for docker daemon
!!4! Announcing the hosted app!!44!
This is the very point of this release. In the past I invested reasonable efforts] to make the chrome packaged app more user friendly, but I had hard times to find the documentation for anything what I planned to add, to enable or reimplement because of the security settings.
Finally I decided to switch to the hosted app model to provide more user friendly UI interaction and faster development of new features.
In case of high demand to the dedicated version, I surely consider to re-release it (the customer is the king), but at the moment I'm believing in the hosted version is much better for the users.
Link: dockery
In case of high demand to the dedicated version, I surely consider to re-release it (the customer is the king), but at the moment I'm believing in the hosted version is much better for the users.
Link: dockery
Monday, August 17, 2015
Using Docker for microservice development
Intro
Before we begin, I'd like to clarify: this is not a Yet Another Basic Docker Tutorial. If you need one, just go to the Docker site or use Google as a rich resource of tutorial links. I used the official site to learn it, but these days a lot of talented colleagues made great tutorials. Also you could get a good overview about what is Docker.
The purpose of this post to make a short introduction about Docker as application platform and microservice runtime environment as a starter of the upcoming blog posts.
The microservice architecture is coming closer every day to us and getting recognized not just by some hot startups and innovative companies, but the mature organizations too. We are still learning how to use their benefits as scalability, simpler maintenance and structure. We are also experiencing the increased costs of microservices as paradigm shift from SOA, orchestration, duplication, increased skill demand on several areas and so on.
Thursday, August 13, 2015
Hosted version of Dockery is available at http://dockery.io/dockery
I totally forgot to release Dockery as hosted web application for simpler access, but from now these days are over. Dockery is available on the dockery.io domain under the link: http://dockery.io/dockery/. Bookmark it quickly and manage your Docker hosts easily with the app.
I believe this is the easiest way to access recent version of Dockery from anywhere, but don't forget: this version is always in beta state :)
I believe this is the easiest way to access recent version of Dockery from anywhere, but don't forget: this version is always in beta state :)
Wednesday, August 12, 2015
Dockery added to the official Docker documentation as client library
I'm proudly announcing: my simple Docker management application Dockery is added to the official Docker documentation as remote api client library. It started as a pet project to learn some Angular basics as a notorious backend developer, but somehow it turned to a fun and my colleague Jens Wlodarczyk convinced me to take it more seriously and popped up the idea to create a Chrome app version too. That wasn't easy for a novice javascript learner, but now it used by other guys around the Earth and I'm getting feedback about what to improve/fix. This is my very first travel into the open source community and I think this is a great source of motivation and gives me extra energy to work on it. The blog of course will focus on different things, but this is a great achievment for me and I'm moved a bit now. Sniffsniffsniff... :)
Monday, August 3, 2015
Pull request build automation for Stash with Jenkins
Intro
Moving toward the frequent releasing is a challenging goal for all organizations. It needs well crafted delivery pipelines, devops mindset to take care about the whole software delivery lifecycle and also needs efficient tooling and methodology from the beginning. The starting point is the definition of a supportive workflow for your SCM. We are using Atlassian Stash as Git server, therefore I looked after for Git based workflows. Click on the links for the detailed description of these workflows, the Atlassian guys made a great job to explain them.
Labels:
build automation,
continuous delivery,
delivery pipeline,
forking workflow,
git,
tl;dr,
tutorial,
version control
Sunday, July 26, 2015
Jenkins DSL scripting - Part 4 - adding our own library to the DSL plugin /TL;DR/
Intro
This is actually the last part of my series about Jenkins DSL scripting. I already discussed the basics with environment setup, job creation and linking, view definition and the importance of the easily reproducible build pipelines with non-pet Jenkins servers. The following part I explained some more advanced topics, like the interaction with the environment, credentials and the customization options with configure block
In this part I'm talking about how to extend the plugin's functionality with your own commands and implement complex logic behind it.
I'd like to say a REALLY big thank you to my colleague Thomas Schneider for his approval to reuse his code snippets and findings in this blogpost. Respect!
I'd like to say a REALLY big thank you to my colleague Thomas Schneider for his approval to reuse his code snippets and findings in this blogpost. Respect!
Labels:
continuous delivery,
delivery pipeline,
jenkins,
scripting Jenkins DSL plugin,
tl;dr,
tutorial
Monday, July 20, 2015
Jenkins DSL scripting - Part 3 - intermediate /TL;DR/
This is the third article in my series about the journey of Jenkins DSL scripting.
In the first part we learned the basics of the DSL plugin features with detailed explanation of the building blocks to enable you to create simple pipelines.
The second part described the side effects of dynamic pipeline creation, the role of seed/boostrap job and finally demonstrated and described a simple pipeline project for an application. They were the basic part of DSL scripting and focuses on the pipeline as a whole.
Now we are entering to the intermediate level and focusing on particular problems of the pipeline creation like passing values via environment variables, using credentials to access protected resources, extending the DSL plugin functionality with the configure block to use non-covered plugin functions and so on.
In the first part we learned the basics of the DSL plugin features with detailed explanation of the building blocks to enable you to create simple pipelines.
The second part described the side effects of dynamic pipeline creation, the role of seed/boostrap job and finally demonstrated and described a simple pipeline project for an application. They were the basic part of DSL scripting and focuses on the pipeline as a whole.
Now we are entering to the intermediate level and focusing on particular problems of the pipeline creation like passing values via environment variables, using credentials to access protected resources, extending the DSL plugin functionality with the configure block to use non-covered plugin functions and so on.
Monday, July 13, 2015
Jenkins DSL scripting - Part 2 - environment setup /TL;DR/
In my first article I wrote about the basics of the Jenkins DSL scripting. I explained my motivation to switch from static Jenkins configuration to a more dynamic one and tried to show the benefits via small examples.
In this part I'm talking about some interesting side effects of dynamic pipeline generation, the role of seed jobs, my development setup and finally I define a basic pipeline as a blueprint for other's project. I hope this entry will be shorter then the first one :)
Subscribe to:
Posts (Atom)