What is GitOps?

I think we should start with questions:

Where do we nowadays deploy our code? Where does it run? Where is it hosted?

Times, when we have manually copied compiled apps to the one, single, runtime environment, are gone. We live in the world of Kubernetes clusters, microservices, serverless, clouds, etc. And even when we look from a single system perspective, we see that probably it is being deployed to multiple environments (development, staging, and production). We live surrounded by multiple runtime environments. Environments that have to be defined, configured, and managed.

We can do this manually, but I think everyone can see that this is not the way. And that is why Infrastructure as code (IaC) concept has been born. Without going into details, IaC gives us the possibility to wrap the definition and configuration of environments into the code. A code that can be executed to create environments for our applications.

So, if we have an infrastructure enclosed in a code, that code (the same as an application code) may be versioned in Git repositories and may be operated by dedicated CI/CD pipelines. And this is what a GitOps is.

To sum up, GitOps is a combination of Infrastructure as Code and Git and CI/CD.

Benefits of GitOps

Let’s think about what benefits give us mentioned combination.

One source of truth

How is our environment configured? Did someone make manual changes in configuration? These questions do not apply when our environments are in the GitOps regime. That is because all changes are now applied through the code as the result of the CI/CD pipelines. There is no place for manual changes because most of the users have no privileges to make them. All rights to make so are now in the hands of CI/CD.

More secure

As mentioned in the point above. All rights to modify environments are now in the hands of CI/CD. It means that most of the users do not need access to the infrastructure. This means that the risk that someone will break something during manual operation on a server/container/cluster is smaller. This also means that the risk of a credential leak is smaller. And last but not least, this also means that managing user privileges and access to the environments is much easier.

Git Merge requests mechanism and team collaboration

All changes in an infrastructure code, when the code is in a Git repository, can be now handled like any other code in Git repositories. I mean, that all changes may be, and should be made in separate branches, which should be merged to the main branch after code reviews. That will for sure increase code quality and will give a possibility to the team to find out some mistakes or poor code parts.

CI pipelines, which can easily test our code

Code reviews do not have to be the only part of a process where bugs are being revealed. We can add tests to a CI pipeline that can find out, for example, some syntax problems. It can be very helpful especially when you think about a YAML syntax that can be very tricky.

Versioning and easy rollbacks

Another benefit of storing your infrastructure code in Git repositories is its versioning. We know what, when, and by whom was changed. If something goes wrong, we can revert our infrastructure to the last working version. Thanks to the automation of CI/CD pipeline deployment and also the rollbacks are easy and fast.

Azure Cosmos DB – basic information you should know

What is Azure Cosmos DB in general?

Cosmos DB is a document database. Document database with an API familiar with SQL query language. This feature distinguishes it from other NoSQL databases. It is worth mentioning that this is not the only API for Cosmos DB. But SQL API is recommended, and in fact, it is the most popular option selected by developers. However, generally, the SQL syntax has its limits. For example, joins across different documents are not possible.

In MongoDb, the support for SQL queries is available as a Preview feature.

Continue reading →

Dlaczego używam osobistej ‘Jiry’ w pracy? Prosty trik na zaplanowanie swojego dnia.

[et_pb_section][et_pb_row][et_pb_column type=”4_4″][et_pb_text]Godzina 7:30 melduję się rano w pracy. Coś na ząb, zielona herbata i zaczyna się… Właśnie startuje najważniejsze kilka godzin tego dnia w pracy. Okienko, w którym mój mózg jest wypoczęty. Już bardziej wypoczęty dzisiaj nie będzie 🙂 Możemy zatem razem, ja i mój mózg, skupić się na zadaniach złożonych, wymagających świeżości i polotu.

Zawsze w tym momencie powtarzam sobie.. Maciek nie spie#$@ tego dzisiaj.

Powtarzam to sobie i zaczynam od najtrudniejszego zadania tego dnia. Tego dnia, jak i każdego innego dnia w pracy.

Continue reading →

7 prostych zasad jak walczyć z błędami poznawczymi

Pamiętam, że będąc młodym programistą, wyobrażałem sobie ścieżkę rozwoju przez nieustanne pisanie kodu.

Jak się później okazało, docelowo wyglądało to trochę inaczej. Początkowo, stopniowo otrzymywałem coraz to więcej swobody. Jednocześnie musiałem zacząć podejmować coraz to więcej decyzji odnośnie do pisanego przeze mnie kodu. Następnie, zacząłem uczestniczyć w spotkaniach wewnętrznych w firmie. Jeszcze później w spotkaniach z klientami. Na każdym z takich spotkań podejmowaliśmy wspólnie mnóstwo decyzji. I to właśnie umiejętność podejmowania dobrych decyzji jest czymś, co wg mnie definiuje dobrego programistę. Ponieważ czasami decyzja, żeby nie pisać kodu, ma większą wartość niż miesiąc kodowania.

W poprzednim poście opisałem jak wielki wpływ na nasze decyzje mają błędy poznawcze. W tym poście skupię się na tym, jak walczyć z błędami poznawczymi, aby podejmować lepsze decyzje i być lepszym programistą.

Continue reading →

Jak programista widzi świat?

Drugim postem na swoim blogu postanowiłem wejść wszystkim programistom do ich głów i zrobić swoistą psychoanalizę postrzegania przez nich rzeczywistości.

Czemu nie? 🙂 Zrobię to na przykładzie fikcyjnych dialogów, fikcyjnych deweloperów na fikcyjnym spotkaniu.

Oczywiście nie mam ku temu żadnego wykształcenia. Jestem deweloperem jak wielu innych, obdarzonym umysłem ścisłym, patrzącym logicznie i racjonalnie na otaczający go programistyczny świat i problemy z jakimi zmagam się na co dzień. Ale czy na pewno, tak bardzo racjonalnie jak mi się wydaje?

Jak działa umysł?

Szybko. Ilość informacji, którą nasz mózg otrzymuje na wejściu jest ogromna. Gdyby chciał to wszystko przetwarzać i analizować wyniki jego pracy przestały by być efektywne. Podobno to kwestia ewolucji. Gdy coś zaszeleściło w prehistorycznych krzakach, nasz pra-pra-…-pradziadek (dajmy na to homo erectus) nie miał czasu na zastanawianie się “czy to aby nie tygrys?”. Aby przetrwać, lepiej dla niego było podjąć decyzję szybko, czyli po prostu schrzaniać gdzie pieprz rośnie. Może to kwestia ewolucji, może nie, ale musimy się pogodzić z tym, że nasz umysł opiera swoje działanie na skrótach myślowych. Właściwie powinniśmy mu być za to wdzięczni. To jest jego fantastyczna cecha.

W ciągu sekundy ludzki umysł otrzymuje około 11 milionów bitów informacji pochodzących z naszych zmysłów (źródło Britannica). Zakładając, że przeciętny człowiek potrafi przeczytać ze zrozumieniem 5 słów na sekundę, daje nam to prędkość świadomego przetwarzania informacji na poziomie 50 bitów/sekundę. Można zauważyć jaką niewiarygodną pracę wykonuje nasz mózg filtrując i kompresując informacje wejściowe do poziomu akceptowalnego przez świadomość.

Ta jego fantastyczna cecha ma jeden mały minusik. Wcześniej wspomniane skróty myślowe niestety prowadzą do błędów… tzw. błędów poznawczych.

Przejdźmy do przykładu.

Continue reading →

Design thinking, co to jest?

Czy programista powinien zajmować sobie głowę design’em? A co to jest ten design? Design patterns – wiadomo znamy, szanujemy. 🙂 A design thinking to co to takiego? 
 
Sam osobiście na temat natknąłem się dosyć przypadkowo. Na tyle mnie on zaciekawił, że postanowiłem pogłębić wiedzę z tego zakresu. Między innymi udało mi się wziąć udział w warsztatach prowadzonych przez Google i PFR. Chciałbym się podzielić z Wami moimi przemyśleniami. Przy okazji jest to mój coming out, czyli początek przygody z blogowaniem.

Definicja

Przeszukując Internet można natrafić na kilka definicji. Design thinking to metoda twórczego rozwiązywania problemów. Design thinking to usystematyzowany iteracyjny proces.
 
Wg Hasso-Plattnera z Institute of Design at Stanford proces ten można podzielić na pięć etapów:
  • empatia
  • zdefiniowanie problemu,
  • pomysły,
  • prototypy,
  • testy.
Na warsztatach prowadzonych przez Google został zaproponowany trochę inny podział. Mianowicie:
  • focus on the user,
  • think 10x
  • be prototype driven.
Z mojej perspektywy design thinking to połączenie w pewien ciąg rzeczy oczywistych, które są przez nas podświadomie marginalizowane w pędzie wytwarzania końcowego rozwiązania. 

A wszystko zaczyna się od pomysłu

Żyjemy w czasach Startup’ów. Jesteśmy bombardowani tysiącami pomysłów i ich realizacji. To sprawia, że w naszych głowach tych pomysłów również nie brakuje. Sam osobiście mam spisaną listę kilkunastu rzeczy, które wpadły mi do głowy i czekają na realizację. To jest super. Co jest jeszcze super? To, że będąc programistami mamy jeszcze prościej, ponieważ od pomysłu do napisania pierwszych linijek kodu jest niedaleka droga. Szybki przegląd koncepcji i można zaczynać programować. Mam super pomysł, zarwę kilka nocek i… i tutaj jest chyba miejsce na cytat. 
 
You got an idea? And you know who thinks that’s a great idea? You.. You are the problem, you are a risk to be managed. 
Ed Hesse
Continue reading →