DEV Community: beatriz gracia

O que é e como funciona o Cloud Native

beatriz gracia — Sat, 04 Mar 2023 23:16:27 +0000

Cloud Native é uma abordagem que permite construir software escalável, resiliente e de alta disponibilidade. Essa abordagem faz uso de tecnologias e princípios de computação em nuvem como arquitetura de microsserviços, containerização e DevOps para permitir uma rápida entrega de novas features e serviços para o usuário final. No entanto, aplicações Cloud Native não são simplesmente sistemas antigos migrados para a nuvem (Cloud Based) e sim novas aplicações e sistemas que foram desenvolvidas para a nuvem, aproveitando todas as vantagens que as plataformas de serviços Cloud oferecem.

Fundamentos

Muitas tecnologias são utilizadas no desenvolvimento de aplicações Cloud Native no entanto alguns conceitos são essenciais para o melhor entendimento da abordagem. Do ponto de vista computacional temos, principalmente, funções e containers. De uma perspectiva arquitetural, temos a arquitetura de microsserviços. A seguir abordarei esses temas de maneira resumida e por fim indicarei algumas fontes que podem ser úteis no processo de aprendizagem.

Containers

Containers são tecnologias que permitem que você isole aplicações em tempo de execução. São como pacotes prontos com todos os arquivos necessários para a aplicação rodar.

Tradução livre de Red Hat: Understanding Linux Containers

No diagrama abaixo podemos observar um exemplo de arquitetura de containers utilizando a ferramenta Docker.

Adaptado de: GeekFlare

Benefícios

Produtividade: Criar imagens de aplicações e iniciar containers com elas é muito mais rápido do que criar máquinas virtuais para rodar as aplicações.
Deploy independente: Utilizando containers (mais especificamente na arquitetura de microsserviços) você poderá fazer o deploy individual de certos serviços da sua aplicação o que melhora também a manutenibilidade das aplicações.
Escalabilidade e otimização: Devido a habilidades dos containers de iniciar e parar em questão de segundos eles se tornam muito escaláveis pois podem reagir a mudanças de carga e necessidade de um sistema. Esse benefício geralmente é aproveitado com plataformas de orquestração de containers como, por exemplo, Kubernetes.
Portabilidade: A famosa frase "Mas na minha máquina funciona" já não é mais tão importante. Como containers possuem todas as dependências necessárias para rodar um software acaba se criando um cenário agnóstico e independente para o software.

Desvantagens

Não é pra tudo: Nem todas as aplicações necessitam de containerização e algumas podem até ser prejudicadas por ela. Monolitos, por exemplo, não tem a necessidade de escalabilidade de imediato e portanto a containerização desses poderia significar um atraso na produção.
Baixa isolação: Os containers compartilham um Kernel único e portanto se esse ficar suscetível a vírus, todos os outros serão afetados. O contrário ocorre com virtual machines, elas possuem isolação e uma não é afetada por um vírus na outra, por exemplo.

Serverless Computing

Serverless é um modelo de desenvolvimento de aplicações que permite que desenvolvedores criem e rodem aplicações sem precisar provisionar ou administrar servidores ou infraestrutura de backend.

Tradução livre de IBM: What is serverless?

É importante notar que, apesar da tradução de serverless ser "sem servidores" não é, de fato, isso. O nome serve para representar a interação que o desenvolvedor tem com servidores: nenhuma.

Atualmente, a maioria das plataformas de serviços em cloud oferecem soluções serverless:

AWS (Amazon Web Services) – AWS Lambda
Microsoft Azure – Azure Functions
GCP (Google Cloud Platform) – Google Cloud Functions
IBM Cloud – IBM Cloud Code Engine

Esses são somente alguns exemplos de serviços serverless, os exemplos acima se encaixam em FaaS (Functions-as-a-service) no entanto existem outros serviços que também são serverless porém não FaaS como por exemplo Azure Container Instances (ACI) e Azure SF Mesh.

Abaixo uma tabela para comparação de functions (funções) com containerized services (serviços containerizados).

FaaS (Function-as-a-service)	Serviços em Container
Faz somente uma coisa	Faz mais de uma coisa
Não pode fazer deploy de dependências	Pode fazer deploy de dependências
Precisa responder a um único tipo evento	Pode responder a mais de um tipo de evento

Microsserviços

A arquitetura de microsserviços permite que uma grande aplicação seja dividida em partes menores e independentes, cada uma com sua responsabilidade.

Tradução livre de Google Cloud: What is Microservices Architecture?

Adaptado de: Cloud native: Using containers, functions, and data to build next-generation applications

Características

Abaixo estão disponíveis algumas características da Arquitetura de Microsserviços, todas as informações abaixo foram retiradas das minhas anotações pessoais de quando fiz o curso Microservices Architecture – The Complete Guide do instrutor Memi Lavi e traduzidas. O link para o curso está disponível nas referências desse artigo.

Componentização de serviços

Design modular é sempre uma boa ideia pois você pode realizar mudanças específicas ao invés de mudar uma grande quantidade de código.
Componentes são partes que em conjunto compõem o software.
Modularidade pode ser atingida utilizando:

Bibliotecas: chamadas diretamente dentro do processo
Serviços: chamados por mecanismos fora do processo (API Web, RPC)

Por que usar serviços?

Deploy independente, usar serviços ao invés de bibliotecas faz com que seja possível realizar o deploy de somente uma parte da aplicação. Se todo o processo é uma biblioteca nós teriamos que fazer o deploy da aplicação inteira novamente (o que seria mais próximo de um monolito do que de microsserviços).
Interface bem definida pois o componente deve ser pensado e arquitetado para exatamente o que deve fazer.

Decentralização

Em projetos tradicionais quase sempre há um padrão para tudo:

Linguagem
Bancos de Dados
Criação de logs

Com arquitetura de microsserviços cada equipe pode fazer suas próprias decisões, baseando-se no que será melhor para aquele serviço específico.

Automatização de Infraestrutura

Na arquitetura de Microsserviços a automatização é essencial.

Ciclos curtos de desenvolvimento são necessários.
Teste e deploy não devem ser feitos manualmente.
Muitas ferramentas para automatização: Azure DevOps, GitHub Actions, Jenkins etc. Design for Failure
Muitos processos e muito tráfego em redes então muita coisa pode dar errado.
O código deve sempre assumir a falha e lidar com ela de maneira elegante.
Observabilidade com logs, tracing é essencial.

Arquitetura Cloud Native

Abaixo um diagrama da arquitetura Cloud Native para referência.

Adaptado de: Alibaba Cloud

Infraestrutura

A camada de infraestrutura é um elemento crucial na computação em nuvem. Ela se refere à infraestrutura física fornecida pelos provedores de serviços em nuvem, que oferecem todo o hardware necessário para a implantação de uma aplicação. Embora o hardware possa não ser visível para o usuário final, ele é vendido como um serviço, conhecido como Infrastructure-as-a-service (IaaS). Essa camada de infraestrutura fornece aos usuários acesso a recursos computacionais escaláveis, como servidores, armazenamento e redes, sem que eles precisem investir em hardware físico e infraestrutura de data center.

Orquestração

Orquestração de Containers automatiza o provisionamento, implantação, networking, escalabilidade, disponibilidade e gestão do ciclo de vida de containers.

Tradução livre de IBM: What is container orchestration?

Existem diversas plataformas de orquestração de containers como Kubernetes, Docker Swarm e Apache Mesos. Nesse momento, a abordagem será feita pensando especificamente em Kubernetes.

Para compreender melhor o conceito de orquestração de containers é mais fácil pensar sobre o problema que essa tecnologia resolve: Uma empresa possui um software grande e complexo, cada serviço é um container e esse software deve ter alta disponibilidade, sempre que um container cair ou parar outro deve ser iniciado no lugar. Esse é o problema resolvido por Kubernetes, controlar esse comportamento.

Algumas vantagens de utilizar Kubernetes:

Balanceamento de carga
Gerenciamento de configuração e secrets
Autocorreção
Manutenção de escalabilidade automática

Middleware

A camada (layer) de Middleware é uma camada intermediária entre as aplicações e a infraestrutura. Abaixo alguns exemplos que podem facilitar o entendimento:

Bancos de Dados (JDBC, Hibernate, ODBC)
Cache (Redis, Memcached)
Mensageria (Apache Kafka, RabbitMQ)
Servidores de Aplicação (Apache TomCat, Jboss, Websphere)

Service Mesh

Uma service mesh, como o projeto open source Istio, é uma forma de controlar como diferentes partes de uma aplicação partilham dados entre si. Ao contrário de outros sistemas de gestão desta comunicação, uma service mesh é uma camada de infraestrutura dedicada construída diretamente numa aplicação. Esta camada visível de infraestrutura pode documentar quão bem (ou não) diferentes partes de uma aplicação interagem, pelo que se torna mais fácil otimizar a comunicação e evitar downtime à medida que uma aplicação cresce.

Tradução livre de Red Hat: What's a service mesh?

Essa pode parecer uma explicação complexa a primeira vista porém é mais simples do que parece. Na arquitetura de microsserviços que, como já comentamos, é importante no desenvolvimento de aplicações cloud native, cada serviço vai exercer somente a sua função. No entanto, por vezes, é possível que um serviço esteja exercendo mais do que a sua função pré-definida e por isso pode se adicionar a camada de service mesh. Ela será responsável por adicionar observabilidade, controle de tráfego e segurança nas suas aplicações, funcionando como um sidecar.

Princípios Cloud Native

Irei abordar 4 dos princípios essenciais de Cloud Native, no entanto é importante notar que existem muitos outros que podem sim ser levados em consideração visto que ainda é um tema em constante discussão e avanço e, portanto, suscetível a mudanças.

Automação

A automação é cada vez mais essencial em sistemas modernos. Ela vem com o objetivo de reduzir o impacto de tarefas repetitivas em implantação, configuração e gerenciamento de aplicações. A automação ajuda a manter a consistência e a segurança do ambiente e permite que desenvolvedores foquem em outras áreas.

Escalabilidade

Possivelmente uma das palavras mais utilizadas nos dias de hoje: escalabilidade. Ela permite que os sistemas se ajustem dinamicamente às demandas em tempo real, como aumento ou diminuição do tráfego em uma aplicação. Para atender a esse requisito, os containers e orquestradores de containers oferecem soluções eficientes para escalar as aplicações. No Kubernetes, por exemplo, é possível usar o Horizontal Pod Autoscaler (HPA) e o Vertical Pod Autoscaler (VPA) para escalar horizontal e verticalmente, respectivamente.

Resiliência

A resiliência é particularmente importante visto que aplicações em cloud são distribuídas estão em ambientes dinâmicos e instáveis. Tendo isso em mente, é necessário que as aplicações sejam projetadas para lidar com falhas e se recuperar rapidamente. As aplicações devem ser capazes de lidar com interrupções de serviços, falha de infraestrutura e problemas de rede. Portanto, se fazem também necessárias soluções de observabilidade para que seja possível detectar qualquer problema rapidamente.

Segurança

Segurança é um aspecto crucial de aplicações cloud native. É necessário garantir criptografia, controle de acesso e também monitorar atividades suspeitas. Os grandes provedores de cloud já oferecem soluções robustas para a segurança. Abaixo estão listadas algumas das soluções da Azure para referência:

Azure Security Center: Recomendações de segurança
Azure Active Directory: Autenticação e gerenciamento de acesso
Azure DDoS Protection: Proteção contra ataques de negação de serviços distribuídos
Azure Firewall: Proteção das redes virtuais
Azure Information Protection: Proteção de dados confidenciais

Conclusão

Esse artigo tratou sobre ferramentas atreladas ao cloud native, arquitetura de microsserviços, computação em nuvem serverless e princípios e arquitetura de uma aplicação cloud native. Espero que tenha sido de alguma ajuda à alguém interessado no tema. Todas as referências estão listadas abaixo para consulta.

Referências

Scholl, B., Swanson, T., Jausovec, P. (2019). Cloud native: Using containers, functions, and data to build next-generation applications. O'Reilly.
Microsoft Azure. Disponível em: https://azure.microsoft.com/en-us/. Acesso em: 03 mar. 2023.
Red Hat: Understanding Containers. Understanding Containers. Disponível em: https://www.redhat.com/en/topics/containers. Acesso em: 03 mar. 2023.
IBM Developer: The true benefits of moving to containers. Disponível em: https://developer.ibm.com/articles/true-benefits-of-moving-to-containers-1/. Acesso em: 03 mar. 2023.
Red Hat: What is container orchestration? Disponível em: https://www.redhat.com/en/topics/containers/what-is-container-orchestration. Acesso em: 04 mar. 2023.
Red Hat: What is a service mesh? 2023. Disponível em: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh. Acesso em: 04 mar. 2023.
IBM: Cloud Native Principles. Disponível em: https://www.ibm.com/cloud/architecture/architecture/practices/cloud-native-principles/. Acesso em: 04 mar. 2023.
Lavi, M. (2023). Microservices Architecture - The Complete Guide. Udemy
Imagem de capa disponível em: https://pixabay.com/illustrations/cloud-computing-technology-network-4246668/

How to use Junit and Mockito for unit testing in Java

beatriz gracia — Sat, 14 Jan 2023 18:33:29 +0000

Originally posted on whathebea.github.io on 23/10/2022

I know today is Sunday but I really felt like writing something. It seems like I can't stop thinking about coding and trying to perfect everything that I am learning. This may be personal but, does anyone else feel this way? Before my internship although I was very dedicated it seems that now I am much more focused. Also, I lost two Valorant matches in a row so I'm feeling a bit down. Maybe writing a post is a way of distracting myself from my losses...

Ok, so today I decided to talk about testing. Answering the question "Why is testing so important?" which I asked myself and talking a little bit about tools and some more things.

Why is testing important?

Imagine you wrote some code and then, later, someone changes something on it. If you have tests ready is very easy to know if the code still works as expected. If you don't have tests, you will have to test the code manually. This is very time consuming and it is very easy to miss something, also, it is expensive, especially if you are working on a big project.

Junit

What is Junit? Junit is a unit testing framework for Java. It is used to test the smallest unit of code, which is a method.

Here is an example of a Junit test:

@Test
public void testAdd() {
    int result = calculator.add(1, 2);
    assertEquals(3, result);
}

When you are testing you must use the @Test annotation. The assertEquals method is used to check if the result of the method is the same as the expected result. If the result is not the same as the expected result, the test will fail.
Here is a test that will fail:

@Test
public void testAdd() {
    int result = calculator.add(1, 2);
    assertEquals(4, result);
}

It fails because 1+2 is not equal to 4.

Mockito

What is Mockito? Mockito is a mocking framework for Java. It is used to mock the dependencies of the class that you are testing.

To use Mockito you have to use @Mock and @InjectMocks annotations. The @Mock annotation is used to create a mock object. The @InjectMocks annotation is used to inject the mock object into the class that you are testing. Here is a full example:

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {
    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    public void testGetUserById() {
        User user = new User();
        user.setId(1);
        user.setName("Beatriz");

        when(userRepository.findById(1)).thenReturn(Optional.of(user));

        User result = userService.getUserById(1);

        assertEquals(user, result);
    }
}

In this example I am testing the getUserById method of the UserService class. I am mocking the UserRepository class because the UserService class depends on the UserRepository class. I am using the when method to mock the findById method of the UserRepository class. I am using the thenReturn method to specify what the findById method will return. In this case it will return an Optional object that contains a User object. I am using the assertEquals method to check if the result of the getUserById method is the same as the expected result, which is the User object that I created manually.

Test Coverage

Test coverage is a measure of how many lines of code are executed during the tests. It is used to measure how much of the code is tested. There are different types of test coverage, but the most common one is the line coverage. It measures how many lines of code are executed during the tests.
IBM has an article talking about how to see your Junit test coverage and you can read it here.

TDD (Test Driven Development)

TDD means Test Driven Development and the name itself is pretty self-explanatory. It is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.
There are different types of TDD, but the most common one is the Red-Green-Refactor cycle. It is a cycle that consists of three steps:

Write a test
Run the test
Refactor the code

So you pretty much write the test and then you write the code to make the test pass. Then you refactor the code to make it more readable and efficient. IBM has a lot of free content about TDD and you can read it here.

Conclusion

I hope my post was helpful! I feel like it really helps me to write about what I learn. I have to push myself a little bit to make code examples and write about it, but I think it is worth it. I hope you liked it and if you have any questions or suggestions, please let me know in the comments! Thanks for reading!

Resources

Connecting an API (Java Spring) to an Android application

beatriz gracia — Sat, 14 Jan 2023 18:31:51 +0000

Originally posted on whathebea.github.io on 21/10/2022

It has been a while since my last post but I swear I haven't given up! It's quite the opposite, actually.

I had to do a project for my internship program which was basically creating a Rest API and connecting it to an Android Application. As it turns out, connecting an API to an app is more of a chore than I thought it would be. I hope I can stick with web development.

I am not allowed to show all the code because it is stored in enterprise GitHub but I want to talk about everything I did and many some things that I struggled.

Android

First: These badges are way too cute for me NOT to use them.

I created the app on Android Studio and to make the HTTP requests I used RetroFit.

Android App Structure

API and Service

Before we move on to the activities I just want to take a look at the configuration for RetroFit.

API

In order to make RetroFit work we have to create an interface with the paths and types of HTTP requests we want to make. Since mine was a pretty simple application there wasn't much to write here.

public interface YourAPI {
    @GET("/api/yourapi")
    Call<List<MyEntity>> getAll();
    @GET("/api/yourapi/{id}")
    Call<MyEntity> getById(@Path("id") Long id);
}

The first get request is to retrieve a list of objects and the second one is to get a single one. You can read more about RetroFit here.

RetroFit Service

The Service part is pretty much standard.

public class RetrofitService {
    private Retrofit retrofit;

    public RetrofitService() {
        initializeRetrofit();
    }

    private void initializeRetrofit() {
        Gson gson = new GsonBuilder()
                .create();
        retrofit = new Retrofit.Builder()
                .baseUrl("your_ip_address")
                .addConverterFactory(GsonConverterFactory.create(gson))
                .build();
    }

    public Retrofit getRetrofit() {
        return retrofit;
    }
}

Activities

Some of the activities that I created are the following (these are not the actual names but I was trying to be descriptive about what each one is)

Main Activity
Splash Activity
Get all Activity
Get by ID Activity

Main Activity

This activity was the first one that was created together with the app. It was an empty activity and I added a logo + 2 buttons.

In Android Studio you can just click and drag components and you also have constraint layouts so, creating a simple screen is not that hard. After you create the screen with the components you have to access the Java Class and add your components so they can do something. Imagine you add a button and you give it the ID myButton, then you would retrieve it like this:

Button myButton = findViewById(R.id.myButton);

My buttons would redirect to another activity. To do that I had to take the button and use a onClickListener. Android Studio is quite useful because as long as you have an idea of what you are doing it does the job of creating most of the code structures for you.

myButton.setOnClickListener(new View.OnClickListener() {
            @Override
           public void onClick(View view) {
               Intent intent = new Intent(MainActivity.this, GetAllActivity.class);
               startActivity(intent);
            }
       });

So there you have it, that's all you have to do to change from one activity to another.

Splash Activity

The Splash Activity is simply a Splash that shows up when you open the app. I will be honest MINE DIDN'T TURN OUT BEAUTIFUL. I can't talk much about Splash Screens because I actually had to search a little bit about them. I found this medium article very thorough and helpful. I probably should work a little bit on my design skills…

Get All Activity

This screen is basically a list with information that was received from the API and so I had to use RecyclerView on it.

What is RecyclerView? you make ask yourself (or me). According to the Android Developer Docs:

RecyclerView makes it easy to efficiently display large sets of data. You supply the data and define how each item looks, and the RecyclerView library dynamically creates the elements when they're needed.

And honestly, couldn't have said it better than that myself. In order to use RecyclerView I created an extra layout: the list_item.xml. What is that? Well, it is what ONE item would look like. Take a look at the picture below for a second.

Do you see that the structure for each e-mail is the same and what changes is the content on each one? Well, that is a RecyclerView!

In this case the list_item.xml would have a name, a subject, the start of a message, how long ago it was sent and a start.

In order to use a RecyclerView you need an Adapter, you can read more about adapters on Android Developer Documentation

And how do we get the information now? Well, now it's finally RetroFit's time to shine!

Create a method to load information
Start retrofit service inside the method
Using our API class with Retrofit
Make the call

After you do all of that then you will have something like this:

    private void loadInfo() {
        RetrofitService retrofitService = new RetrofitService();
        YourApi yourApi = retrofitService.getRetrofit().create(YourApi.class);
        yourApi.getAll()
                .enqueue(new Callback<List<MyEntity>>() {
                    @Override
                    public void onResponse(Call<List<MyEntity>> call, Response<List<MyEntity>> response) {
                        // what will you do with the response?
                    }

                    @Override
                    public void onFailure(Call<List<MyEntity>> call, Throwable t) {
                        // what will it do if it fails? e.g: a toast
                    }
                });
    }

Get by Id Activity

I think you can guess that this activity is pretty similar to the last one except we don't have a RecyclerView. It's just layout with what would be equivalent to a single item from the list.

The loadInfo method is almost exactly the same but one thing: I won't be calling or receiving a list.

Why did I struggle with RetroFit?

Looking back now the answer would be: because I didn't pay enough attention to small things.

Things like:

Typos
Mistaking the path for the requests
Remembering that when I make the get request by ID I don't get an array of objects as a response, I get a single object
Importing the wrong class
Trying to make things much more complicated than what they truly are.

Spring

Spring was a MUCH easier ride than Android. Did I make mistakes? Nope! Where there things I could have done better? Most definitely yes. I made a checklist and I'll leave it here for you people to read it.

[x] Create Project Structure (Spring Initializr)
[x] Create Model
[x] Create Controller
[x] Service Layer Implementation
[x] Create Repository to deal with database operations
[x] Creating Dto and Dto converter
[x] Unit tests on Controller layer
[x] Unit tests on Service Layer
[x] Connect API to MySql database

An api for big companies probably has much more than this but well, that's what I did.

Dependencies

Spring Data JPA
Spring Web
Spring Boot Dev Tools
MySql Driver
SpringFox Boot Starter
SpringFox Swagger 2
SpringFox Swagger UI

Overview

Model

Here is an example of something the model should look like.

@Entity
@Table(name="YOURAPI")
public class MyEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "name")
    private String name;

    // constructors
    // getters and setters
}

It's pretty self-explanatory:

The @Entity annotation specifies that the class is an entity and is mapped to a database table. The @Table annotation specifies the name of the database table to be used for mapping. @id specifies that it is the primary key and @GeneratedValue specifies how it should be generated. Then we have a single @column which specifies the name of the column.

After that, you just have your constructors and getters and setters. For my project I had a default constructor (empty) and two others, one with the id field and other without it. The getters and setters are also pretty standard, you can just generate them as you would. (Right Click > Source > Generate Getters and Setters)

Controller

There isn't anything special about the controller just like there wasn't with the model.

@RestController
@RequestMapping("/api/yourapi")
public class MyEntityController {

    @Autowired
    private MyService myService;

    @GetMapping
    public ResponseEntity<List<MyEntityDto>> getAll() {
        return new ResponseEntity<>(myService.getAll(), HttpStatus.OK);
    }
}

I actually forgot to put the @RestController annotation the first time I wrote the code and guess what? It didn't work. Don't forget your annotations!

@RequestMapping just maps the url path, you have @Autowired to do dependency injection of the service class and you have a pretty standard get request.

The DTO Pattern

DTO means Data Transfer Object. Is it a must? I am not sure. I mean, if you are just studying and making an api that will possibly never see the sunrise, then yeah, I would guess it's not a must. But as far as I've read it is an Enterprise application architecture pattern which means it solves problems in large systems. It's probably very interesting to know how it works.

The best explanation for the DTO pattern that I found is from Baeldung and I definitely would recommend the read!

Happy Endings

The happy ending is that I actually finished my project and can go back to studying Angular and keep finding more stuff to do. I came to the conclusion that I also must practice a little bit more of my designing skills because they are lacking quite a bit.

Besides that, everything is great! I focused a lot on Android here because my main issues were there and finding the solutions was not as easy as one would expect.

If you have any questions or want to know more about anything that I post here just contact me!

@whathebea on Twitter

Beatriz Gracia on Linkedin