Forem: @educostadev

How I Study for AWS Certification using Notion and FlashCards

@educostadev — Fri, 08 Oct 2021 18:44:05 +0000

In this post, I want to share my personal way of studying for AWS Solution Architect Certification using the amazing course from Adrian Cantrill. I have been improving my way of learning over time and I’m always open to trying new things. Learn about how to learn, productivity, and time management is a subject that I like (PT-BR Lecture I did about the subject) and since I started study AWS I do my best to make this journey fun and productive. So I hope that showing what I do today can give you insights to try something new and also find what works best for you.

I use Notion.so to organize my notes and digital content. Since I start to use it I felt more productive because everything I write is easily accessible in one place. You can also create a full Knowledge Management System using Notion if you want.

When I watch the training video for the first time I choose a time where I can give full attention to the content. Some of the contents are totally new to me, which is good to learn correctly for the first time. While watching I carefully:

Listen with attention: The first time I listen to what is said is the most important to me. if I did not understand I came back and listen again if even listening again I did not understand I make a note to research more later.
Select what I judge to be important: The content is dense with a lot of small details so it is hard to select everything to make notes, so when I see something and I think it is important or the instructor gives a warning bout it, I select it to take my notes.
Translate with my words: Take good notes is not copy exactly what is said. So I pause the video and start to write the note with my own words and what I understood about the topic.

The output of this process is a collection of bullet points like that:

IAM Role is the solution for a situation where you need to give access to AWS resources a big number or identities outside your organization due to the fact it is easy to manage or if the number is higher than 5k dues the IAM User limit.
IAM Role is useful for “Cross account access”, in a situation where you have one AWS Account A that needs to access a resource on AWS Account B, an IAM Role on AWS Account B can be created to be assumed and give that access.
In a situation that an IAM Role is assumed to add objects to an S3 Bucket, the object owner is the IAM Role.

After finished the videos I review the notes and fix mistakes in the grammar or meaning. So, I convert all-important ones into a collection of Questions & Answers.

These are an example of Questions I created based on my understanding from the previous notes:

What is the solution for a situation where you need to give access to a big number of identities outside your organization? Use IAM Roles due to the fact it will be easier to manage or when the number is higher than 5k due to the IAM User limitation of 5k.
What is the solution for a situation where you need to give access to other AWS account by implementing a “Cross-Account Access”? Create an IAM Role on the account with the resource and allow it to be assumed by identities by the other account.
When an IAM Role is assumed by identity to add an Object in the S3 bucket, which one is the Object owner? The IAM Role is the owner of the Object within the s3 bucket.

Every question should be created within a “toggle” within Notion to allow it to be converted to FlashCards later. Create good Q&A is something you improve over time. The idea behind FlashCards is to use the Space Repetition method to review the topic.

I copy the block of questions and paste it inside a new Notion page, so I export it as HTML and use the 2anki.net website to convert it into the Anki deck. Anki is a Space Repetition Sofware (SRS) for Windows, Linux, Mac, Android and iOS, well know for managing flashcards.

Exporting Notion page

After downloaded the deck file, I double-click over it, and it is imported within my Anki within a new deck. It’s time to review it, add tags, and make minor adjustments when necessary.

Importing cards to anki

So, I moved all of the new cards to the Main Deck I created, with sub-decks for better organization.

Moving cards to sub-decks

Anki desktop allows you to add a lot of smart plugins like Cloze deletion to hide part of the word pressing (ctrl+shift+c) over the word or the image occlusion to hide part of images.

Take good notes does not mean it will be faster or easier. I spend two or three more times doing this process. The difference is that I do it once, and I study being active rather than passive by just consuming content. I also do practical exercises that the course provides, and this helps me fix the knowledge. The next step for me is to add the Feynman technic in this process. Recently I read about the zettelkasten-method and looked cool.

This is my way of study for AWS. Share in the comments what method have you been using, what works for you?

The post How I Study for AWS Certification using Notion and FlashCards appeared first on Be Cloud Native.

3 tools to make the commits in your repository more professional

@educostadev — Tue, 19 May 2020 16:54:47 +0000

Show professionalism and maturity through your repositories applying good practices to write commit messages

A management version repository that has an organized history of changes and good commit messages shows maturity and professionalism. This organization begins writing commit messages that make clear the intention behind the change made and also has a guideline followed by all the team.

In this article, we will see how you can structure the commit messages in your repository and apply some good practices that can be shared by all the team. We will make use of tree tools to help us to write good commit messages, validate, and make sure that all the rules are being followed.

The following good practice and tools can be applied to Git repositories no matter what kind of programming language this repository keeps track of.

The art of writing good commit messages

Writing good commit messages can be considered an art. And mastering this art takes time and practice. When making a commit of code we can see it as a picture of our work. If the code is a picture then the commit message is a subtitle that puts a description of our work.

When it is time to commit, the developer sees himself free to write a description of his work. Each one has a way to write and in a team, this can lead us to many problems. Without a guideline with some rules to follow and structure the message, we can end with a repository to just stock code without taking all the advantages the tool provides. Later, when we need to go back and check the history to find something, all commit messages can be a mess and make no sense.

The article “How to Write a Git Commit Message” is one of these texts to keep bookmarked. Although there is no main guideline to be followed, we can take some good rules like:

Write the subject using the imperative mood
Limit the number of characters of the subject
Do not end a subject with a period punctuation
Use the body message to describe the why vs how
Limit the number of characters of the body and wrap the text
Separate the subject and body with a blank line

Following rules like these without a tool to help is a pain. We will show how you can write commit messages always with the same structure and better describe the intention of your commit.

Tree tools will be used. These tools were written in javascript and despite the development language and the use of Node.js to make it work, the repository can hold code in any language.

The tools are the following:

Commitlint
The commitlint is a tool that validates the message following a set of rules and good practices. It throws an error when a rule is violated.

Husky
The Husky is the tool that adds scripts (hooks) trigged before (pre-commit) and after (post-commit) your commit. It will be responsible to execute the commitlint to analyze the message before the commit happens and avoid that bad messages be sent to the repository.

Commitizen
The commitizen is the tool responsible to guide the developer through the writing of the message. A sequence of options will be shown and filled by the developer.

Pre-requirements

As said before, we will use the tools, commitlint, husky, and commitizen. All of them have as a pre-requirement the node.js and Git installed. Let’s see how you can install the node using a Linux machine. If you are using Windows you can follow this tutorial.

Installing the nvm and node.js

The nvm is version manager for node.js. Let’s install it first and use it to install the node.js. If you use the bash shell, open the terminal and run the following command:

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

Close and open the terminal again and run the following command to see if the nvm is installed with success:

$ nvm --version0.35.3

Se você utiliza o zsh como shell, será necessário alguns passos adicionais para concluir a instalação.

Vamos agora instalar o node.js através do nvm. No momento da escrita deste artigo, a versão estável é a 12 (12.16.2)

$ nvm install node 12

Check if the node installation is working:

$ node -vV12.16.2

Also, check if the package manager npm is working:

$ npm --version6.14.4

Configuring your repository

The steps to configure your repository should be done only once and preferably before the developers start to make commits. After this configuration, all developers can make a clone of the repository, and before starting to work they need to execute the command “nvm install” into the root folder. If the repository is already configured the following steps should not be followed.

After installing the node.js let’s install and configure other tools in the Git repository. To use the tools Commitlint, Husky and Commitizen you need first initialize it with the “git init” command, however, if you use remote version management like GitHub or Bitbucket you can create the repository remotely and clone it in your local machine. Just in case you want to follow this tutorial in your local machine with a fresh repository run the following command.

$ mkdir <nome-do-repositorio>$ cd <nome-do-repositorio>$ git init

Let’s create or change the file .gitignore to ignore the node_modules folder. This folder will store the tools.

$ echo “node\_modules/” >> .gitignore

Before start, the installation of the tools lets create a package.json file. It is responsible to store the dependencies and configuration of the tools. Run the following command and a new file package.json will be created in the current folder.

$ npm init -y

Now, let’s install the commitlint that will be responsible to validate your commit message following a set of rules. Run the following command and the tool will be installed within the node_modules folder and a new entry will be added into the package.json file.

$ npm install @commitlint/cli --save-dev

It’s time to install the config-conventional. It is the set of rules that will be followed by our commit messages_._ Run the following command and the files will be installed within the node_modules folder and a new entry will be added into the package.json file.

$ npm install @commitlint/config-conventional --save-dev

In this step, it is necessary to configure the commitlint to use the validation rules from config-conventional. So, let’s create the commitlint.config.js file with the following command:

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

The next too to be installed is the Husky. It is responsible to receive events from the Git and trigger the commitlint to validate the commit message. Run the following command.

$ npm install husky --save-dev

For configuring what are the events where the Husky will listen add the following text into the package.json file.

WARNING : If in the code below you find the symbol && replace it by && some browser renders the code wrong.

"husky": { "hooks": { "commit-msg": "commitlint -E HUSKY\_GIT\_PARAMS", "prepare-commit-msg": "exec < /dev/tty &amp;&amp; git cz --hook || true" } },

According to the git documentation, during the event “commit-msg” it is possible to format or validate the message. The vent “prepare-commit-msg” allows us to execute commands before the commit editor is opened. Are in these events that commitzen will work and guide the user to write good commit messages.

To install the commitizen run the following command:

$ npm install commitizen --save-dev

We also need to configure it to work following the validation rules form the config-conventions. Run the following command:

$ ./node\_modules/.bin/commitizen init cz-conventional-changelog --save-dev --save-exact

We are done! Now we have configured the git repository and we can test if everything is working as expected.

Making commits in a configured repository

Add all the changes to the management version system and run the commit command:

$ git add .$ git commit

Now, you will be guided to build your commit message. It’s also a good practice don’t mix more than one change into a single commit, the commit must be atomic and do not put the code into the repository into a state of failure with compile errors or tests broken.

Choose the type of change that is being made. For this example let’s choose “feat”:

ᐳ git commithusky > prepare-commit-msg (node v12.16.2)cz-cli@4.0.4, cz-conventional-changelog@3.1.0? Select the type of change that you're committing: (Use arrow keys)❯ feat: A new feature fix: A bug fix docs: Documentation only changes style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) refactor: A code change that neither fixes a bug nor adds a feature perf: A code change that improves performance test: Adding missing tests or correcting existing tests (Move up and down to reveal more choices)

If your repository has more than one module you can specify the scope of the change. Let’s skip this step, just press enter key:

? Select the type of change that you're committing: feat: A new feature? What is the scope of this change (e.g. component or file name): (press enter to skip)

Write the subject. Remember that it’s a good practice to write the subject using the imperative mood.

? Select the type of change that you're committing: feat: A new feature? What is the scope of this change (e.g. component or file name): (press enter to skip) ? Write a short, imperative tense description of the change (max 66 chars): (55) configure the repository for commit message conventions

Write the description to tell why the change was made.

? Provide a longer description of the change: (press enter to skip) Specified a commit message convention for better track the changes in this repository through the use of the tools commitizen, commitlint and husky.

In the next two steps let’s specify that the changes do not introduce breaking changes and it is not related to any open issue.

? Are there any breaking changes? (y/N) N? Does this change affect any open issues? (y/N) N

Your default text editor will be opened with a message preview that will be committed. Close the editor and the commit will be made.

[master 47bb6b3] feat: configure the repository for commit message conventions 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 dummy.txtᐳ git logcommit 47bb6b3f6f1b37776ce365c7589345ffe3c4ecbd (HEAD -> master)Author: Eduardo Costa Date: Mon Apr 27 13:20:38 2020 -0300 feat: configure the repository for commit message conventions Specified a commit message convention for better track the changes in this repository through the use of the tools commitizen, commitlint and husky.

Conclusion

The commit messages are a very important way to register the changes made into the repository and writing a good message is not an easy task. Using some tips, like to write the title in an imperative mood and the message body describing why the source code changed help us to create good messages.

Standard commit messages are evidence of maturity and professionalism and improve the reliability of the history of changes into the repository, it also helps us to undo some changes and track the cause of issues.

Using some automation tools like Commitlint, Commitizen and Husky, ensure that rules will not be broken and help developers to write good commit messages.

What next

Besides the shown benefits, standardized commit messages are a requirement to automate the semantic versioning, an important topic of software configuration management. There are some tools like semantic release, that can automate this process and besides that, to create a version tag in the branch and also generate the changelog. This is a good topic to start studying and write a new article.

This article was written by Tulio Polachini e Edu Costa feel free to leave a comment if you have some question.

The post 3 tools to make the commits in your repository more professional appeared first on Be Cloud Native.

Integration test with TestContainer

@educostadev — Thu, 20 Feb 2020 02:47:50 +0000

Test the integration layer of your java application with a real Postgres instance using the TestContainer library

Creating efficient integration tests is a common challenge when building microservices. Ensure the environment equality among the development and the production environment can be a pain. Mainly when the tools and services require too much hand configuration. When this happens, we usually take a short cut to adopt lightweight tools for the development and test environment. This makes the difference between the environments even bigger.

The guidelines Twelve-Factor Apps tell us that environment equality is one of the success keys to build cloud-native applications. Developing and testing on similar environments allow us to create resilient applications that bring safety and speed to deploy.

In this blog post, we will see how to create an integration test using the Testcontainer library. The test will start a PostgreSQL container and run reading and writing tests on a real database instance.

What is Testcontainer?

Testcontainer is a java library that gives us support to create unit tests. It provides lightweight and throwaway instances of common databases or any application that ran into a Docker container. It also makes easy the creation of integration tests using container and without using complex configurations

Pre-requirements

To run the example code available on Github, you will need to have installed the git and an IDE. Besides that, you also need to have the Docker and be able to perform the following command:

docker info

If you are using Linux, look that the command does not have the “sudo” prefix. You must be able to execute this command without this prefix because during the test running the library will use the Docker to download images and create containers.

To run the docker command without the “sudo” prefix, your user should be added to the docker user group by the following command:

sudo usermod -aG docker $USER

After running this command you will need to log-off and log-in to the changes take effect.

Example project

This project has an integration test that starts a PostgreSQL container, sets up the database initial status running a SQL script, runs the test and in the end, destroys the container.

To see the code, clone the git repository running the following command:

git clone https://github.com/educostadev/poc-testcontainers.git

Import the project in your IDE as a Maven project. If you use IntelliJ, this link has more information about how to import a Maven project.

The Testcontainer integrates well with JUnit4 and JUnit5 using dependencies specified within the pom.xml. Open the pom.xml file from the code example and look at the dependencies responsible for the use of Testcontainer with JUnit5.

<dependency>
   <groupId>org.testcontainers</groupId>
   <artifactId>junit-jupiter</artifactId>
   <version>1.12.3</version>
   <scope>test</scope>
</dependency>

If you are using a database already supported by Testcontainer then you will need to add in your project the correct dependencies. Here in_ this link_, you can find a list of databases supported by the Testcontainer. In our example, we are using a PostgreSQL instance, and the following dependency is required:

<dependency>
   <groupId>org.testcontainers</groupId>
   <artifactId>postgresql</artifactId>
   <scope>test</scope>
</dependency>

The project files follow a standard Spring Boot application. Within the application.yml file, you can find all the database connection entries. Pay attention to the use of environment variables named DB_URL, DB_USERNAME, and DB_PASSWORD.

server:
  port: 8083
logging:
  level:
    ROOT: info
    org.hibernate.tool.hbm2ddl: debug
    org.hibernate.SQL: debug
    org.hibernate.type.descriptor.sql: trace
spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
    driver-class-name: org.postgresql.Driver
    hikari:
      maximum-pool-size: 5
      connection-timeout: 20000
    initialization-mode: always
  jpa:
    database-platform: org.hibernate.dialect.PostgreSQLDialect
    hibernate:
      ddl-auto: create

The DummyDao class makes use of the jdbcTemplate library to execute SQL queries in the database. This is the class that will be tested using the PostgreSQL container.

@Repository
public class DummyDao {
  @Autowired
  private JdbcTemplate template;
  public Dummy findDummyById(int id) {
    return template
        .queryForObject("SELECT * FROM dummy_test where id=?", new Object[]{id},
            new DummyRowMapper());
  }

  public List readAll() {
    return template.query("SELECT id,name_value FROM dummy_test", new DummyRowMapper());
  }

  public int save(Dummy dummy) {
    return template.update("INSERT INTO dummy_test (id,name_value) VALUES (?,?) ",
        new Object[]{dummy.getId(), dummy.getName()});
  }

  static class DummyRowMapper implements RowMapper {
    @Override
    public Dummy mapRow(ResultSet rs, int rowNumber) throws SQLException {
      return new Dummy(rs.getInt("id"), rs.getString("name_value"));
    }
  }
}

Look at the test bellow, it injects a DummyDAO instance and the following methods execute a read and write integration tests. Because this is an integration test, we are not_ [_mocking](https://pt.wikipedia.org/wiki/Objeto_Mock)_ the behavior of the _DummyDAO class, this means that a real connection with the database is required.

A static instance of the PostgresSQL container is created in the class beginning. Even though this instance is not used in the class body, it is responsible to create and start the container.

The static initialization of the attribute allows us to reuse the same container instance in other running tests. This avoids that a new container is created and destroyed on an every executed test. Tha @TestContainer and @Container annotation takes care of the container life cycle and allows that it be started once and destroyed when the test ends.

@SpringBootTest
@ContextConfiguration
@Testcontainers
public class DummyDaoTest {

@Container
public static PostgreSQLContainer postgreSQLContainer = CustomPostgresContainer.getInstance();

@Autowired
DummyDao dao;

@Test
void injectedComponentsAreNotNull() {
  assertNotNull(dao);
}

@Test
void save_new_value() {
  Dummy value = new Dummy(1000, "dummy");
  int affectedRows = dao.save(value);
  assertEquals(1, affectedRows);
}

@Test
void read_all() {
  assertThat(dao.readAll()).isNotEmpty();
}

}

The CustomPostgresContainer _class is responsible for download the image, create and start the _PostgreSQL container in the alpine version. You could use any available image from Docker Hub, or even a customized image.

In this demonstration example, the container is started and a SQL Script is loaded to set up the database with some data.

The overridden method start() plays an important role in this test infrastructure. It gets the URL, user, and password from the started container and writes these values on environment variables. This allows the test to connect with a real database instance.

public class CustomPostgresContainer extends PostgreSQLContainer {

  private static final Logger logger = LoggerFactory.getLogger(CustomPostgresContainer.class);
  private static final String IMAGE_VERSION = "postgres:alpine";
  private static CustomPostgresContainer container;

  private CustomPostgresContainer() {
    super(IMAGE_VERSION);
  }

  public static CustomPostgresContainer getInstance() {
    if (container == null) {
      container = new CustomPostgresContainer();
    }
    return container;
  }

  @Override
  public void start() {
    super.start();
    logger.debug("POSTGRES INFO");
    logger.debug("DB_URL: " + container.getJdbcUrl());
    logger.debug("DB_USERNAME: " + container.getUsername());
    logger.debug("DB_PASSWORD: " + container.getPassword());
    System.setProperty("DB_URL", container.getJdbcUrl());
    System.setProperty("DB_USERNAME", container.getUsername());
    System.setProperty("DB_PASSWORD", container.getPassword());
  }

  @Override
  public void stop() {
    //do nothing, JVM handles shut down
  }
}

The summary of the test execution flow using the Testcontainer is the following:

The first test from the tests tacks is started;
The getInstance() method from CustomPostgresContainer class is invoked.
The Testcontainer library checks if the required image exists locally;
If the image does not exist locally, it is downloaded from the docker hub;
A container is created, based on the downloaded image and the database is started;
All the following tests use the started database;
At the end of all test execution, the container is destroyed.

Conclusion

In this article, we saw how the Testcontainer library makes easy the creation of test integration with the use of docker images. It allows us to decrease, the environment disparity between the development environment and production environment, it also brings safety to deploy. The library is evolving daily and brings native support to many other databases and allows you to create your image. In this video, Kevin Wittek one of the Testcontainer committers show us more about the library.

Have you created integration tests that use real instances of services? What tools did you use? Drop a comment below!

The post Integration test with TestContainer appeared first on Be Cloud Native.

Weekly Cloud-Native Digest #21

@educostadev — Thu, 21 Nov 2019 11:59:40 +0000

Save time and stay up-to-date with what’s going on in the Cloud-Native ecosystem. Every week a collection of useful links with videos, articles and more.

The post Weekly Cloud-Native Digest #21 appeared first on Be Cloud Native.

Weekly Cloud-Native Digest #20

@educostadev — Tue, 12 Nov 2019 11:03:21 +0000

Save time and stay up-to-date with what’s going on in the Cloud-Native ecosystem. Every week a collection of useful links with videos, articles and more.

The post Weekly Cloud-Native Digest #20 appeared first on Be Cloud Native.

Weekly Cloud-Native Digest #19

@educostadev — Tue, 05 Nov 2019 11:14:43 +0000

Save time and stay up-to-date with what’s going on in the Cloud-Native ecosystem. Every week a collection of useful links with videos, articles and more.

The post Weekly Cloud-Native Digest #19 appeared first on Be Cloud Native.

Weekly Cloud-Native Digest #18

@educostadev — Tue, 29 Oct 2019 11:13:30 +0000

Save time and stay up-to-date with what’s going on in the Cloud-Native ecosystem. Every week a collection of useful links with videos, articles and more.

The post Weekly Cloud-Native Digest #18 appeared first on Be Cloud Native.

Installing Google Cloud SDK on Windows

@educostadev — Wed, 23 Oct 2019 10:46:59 +0000

Google Cloud SDK (Software Development Kit) is a Command-line interface for Google Cloud Platform products and services. It has a set of useful tools for manage VM Instances, network, firewall, disk storage and more. In the video below you see the steps to install it on Windows. If your operating system is other than windows, visit the Google Cloud Quickstarts documentation and follow the steps according to your operating system.

Check other tutorials for Google Cloud Platform.

The post Installing Google Cloud SDK on Windows appeared first on Be Cloud Native.

Weekly Cloud-Native Digest #17

@educostadev — Tue, 22 Oct 2019 10:47:59 +0000

Save time and stay up-to-date with what’s going on in the Cloud-Native ecosystem. Every week a collection of useful links with videos, articles and more.

The post Weekly Cloud-Native Digest #17 appeared first on Be Cloud Native.

5 facts that will make you rethink the use of Microservice

@educostadev — Wed, 16 Oct 2019 11:05:30 +0000

Microservice architecture has been widely used to build scalable and resilient applications. Every company wants to build application fault-tolerant and be able to build and deploy new features fast. Although Microservice architecture is a tool to achieve these goals, it is also a tool that has some requirements to be applied with success. This article explores some of these requirements.

You should rethink use Microservices when…

1. The application is too small

When the application is too small, the cost of maintaining a microservice up and running is higher than the benefits it generates.

2. The problem domain is unclear or uncertain

Microservices are created based on the capabilities that you identify on the domain you are working on. This means that you will start by the creation of a domain model with boundaries, aggregates, entities, and interfaces. When the problem domain is unclear or uncertain, changes can happen more often than you expect. Boundaries will move, aggregates will consolidate, interfaces will change, the model will split. Refactory is good toimprove the design of existing code but also can slow down the team when the contract with other services is broke. A monolith, in this case, is much more flexible.

3. The Organization has a rigid business structure and cannot change

The system architecture tends to reflect the business organization. TheConway’s law states:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Mel Conway

Organization sometimes will need aBusiness Refactory to build Microservices. Different teams have different priorities that can create delays and conflicts. On Microservice architecture each service (or a small set of them) are managed by small and self sufficient teams.

4. The team lacks experience to understand the microservice concepts or conceptual design

Bad design architecture leads to a tightly coupled distributed monolith. And all the nightmare associated with it, delays, complexity, coupling deploy times. The lack of knowledge of DDD and commons patterns for Microservices is an open door to take shortcuts and implement anti-patterns. Managers also need to be comfortable with refractories and not blame the team due to bad choices. Fail often, fail early, fail fast is desired, but it is not an easy thing to learn because of thesunk cost fallacy.

5. The team turnover is high or lacks experience with delivery pipeline

Build and deploy microservices demands skills that go beyond programming and problem-solving. The team needs experience with test-driven development, code review, DevOps, infrastructure as code, continuous integration and deployment. If the turnover is high or the team lacks this skill there is a chance you ended up with adistributed monolith.

This article was based on thisgreat post from Charles Féval where he explains some of the downsides of adopting a Microservice Architecture.

What other facts you faced that made you rethink in adopt Microservice architecture? Drop a comment here.

The post 5 facts that will make you rethink the use of Microservice appeared first on Be Cloud Native.

Weekly Cloud-Native Digest #16

@educostadev — Tue, 15 Oct 2019 10:30:54 +0000

Save time and stay up-to-date with what’s going on in the Cloud-Native ecosystem. Every week a collection of useful links with videos, articles and more.

VIDEOS

-[Principles Of Microservices] In this talk, Sam Newman shows us some principles of Microservice Architecture with good examples and suggestions of tools to address some of them
-[Don't Walk Away from Complexity, Run] A must watch presentation with an amazing highlight on some types of complexity you commonly found in software. Learn to identify it and run from it. By @venkat_s at @GOTOcon
-Mastering Chaos A Netflix Guide to Microservices - In this talk @ZenTeknologist talks about the chaotic and vibrant world of microservices at Netflix.

CQRS & ES

-1 Year of Event Sourcing and CQRS - Great post which describe the journey on implementing an application based on CQRS and Event Sourcing principles. By @teivah at @hackernoon
-Free eBook Exploring CQRS and Event Sourcing - Focused on building highly scalable, highly available, and maintainable applications with the Command & Query Responsibility Segregation and the Event Sourcing architectural patterns.

MICROSERVICES

-Microservice Observability, Part 1: Disambiguating Observability and Monitoring
-Microservices - Not a free lunch! - Microservices one of these ideas that are nice in practice, but all manner of complexity comes out when it meets reality. Check this great article from @benjaminwootton .
-Introducing Azure Spring Cloud: fully managed service for Spring Boot microservices - To help make it simpler to deploy and operate Spring Cloud applications, together with @pivotal Microsoft have created @Azure Spring Cloud. By @Johnmont
-Microservices Testing Strategies, Types & Tools: A Complete Guide -

CLOUD & OTHERS

-The power of the cloud - Processing 40 TB of code from ~10 million projects with a dedicated server and Go for $100
-How Slack Built Shared Channels - See the technical decision behind the implementation of Shared Channels on @SlackHQ , the implications of the decisions, and how they're working on scaling for the future.
-IBM Cloud Creating a Lite Account - What about Creating a Lite Account on IBM Cloud and start having fun ? In this post @NeoPrimeAws cover the steps to you start with @IBMcloud with a good introduction to the main services available.

-The Observability Pipeline

The post Weekly Cloud-Native Digest #16 appeared first on Be Cloud Native.

8 tips to get your dream job and also improve your curriculum

@educostadev — Fri, 11 Oct 2019 16:50:55 +0000

Dream job! Talking with Bruno Souza (the Brazilian Java man) about career, he gave me golden tips on how to get your dream job and also improve your curriculum. Check this out

Tip Number 1#

The best offers is the one where the company knows and trusts you. When this happens, your curriculum does not matter. So keep improving your network and share knowledge as much as you can.

Tip Number 2

Create a curriculum is like to create a marketing folder to sell a product. You do not sell a product talking about its features, but about the benefits it brings. Talk about your benefits!

Tip Number 3

Tell in your curriculum about what you are good and what you can bring to the company you are applying to.

Tip Number 4#

When a company reads your curriculum they are looking for what you can do for them. How can you help them? Show how in your curriculum!

Tip Number 5#

Show the transformation you can cause to the people you work.

Tip Number 6#

Whether a company will pay 100k/year for a position, it will be 1 Million in 10 years. Why the company should choose you? Show them why.

Tip Number 7#

Make your curriculum easy to read. You can, for example, create sessions divided by companies or projects you worked.

Tip Number 8#

Look on the position requirements you are applying and add on your curriculum the values you can bring for the company that matches the offer. A directed curriculum is even better than a generic one.

Can you add more tips here? What do you think is important to get your dream job? Drop a comment bellow.

The post 8 tips to get your dream job and also improve your curriculum appeared first on Be Cloud Native.