Skip to content

DEVCOR 350 - 901

Aim of this course

DevNet certification is Cisco’s newest certification track, designed to help network professionals and software developers who want to write applications and develop integrations with Cisco products, platforms, and application programming interfaces (APIs).

There are five part:

  • Software Development and Design
  • Using APIs
  • Cisco Platforms
  • Application Deployment and Security
  • Infrastructure and Automation

“Software Development and Design”

The front-end is the part of the application that receives input from a client in a secure and efficient manner. The back-end is the part of the application that processes requests, executes business logic, and stores information.

The front-end/back-end concept is widely used in web development.

The most common front-end languages are HTML, CSS, and JavaScript as well as various frameworks using these languages

The back end (also called the “server side”) of a website processes and stores data and ensures everything on the client side works correctly. It is the part of the website that does not come in direct contact with users. Back-end development languages are Java, C++, Python, PHP, and so on

Load Balancing

Load balancing has other benefits besides performance scalability

  • High availability and reliability: Requests are only sent to servers that are online and healthy.
  • Reduced downtime: A single server failure does not bring service down.
  • Redundancy: Operational servers take over a failed server’s load.
  • Flexibility: Servers may be transparently added or removed from their group, as needed.
  • Efficiency: The load may be distributed across servers based on their load, response time, number of connections, and so on.

Modularity Modularity is a software design technique that focuses on separating the program functionality into independent and interchangeable modules that contain everything necessary to execute only one aspect of its functionality. Functions, objects, and modules are all examples of the modularity in the application design.

Modular applications, if built correctly, are much more reusable than nonmodular ones since modules may be used again in other projects without a change. Other benefits of the modular design include the following:

  • Application becomes more flexible because it’s easy to replace one module with another.
  • Projects may be broken down into several smaller independent projects.
  • Code is much easier to understand and troubleshoot.
  • Code is easier to test because each module may be tested individually.
  • Code is easier to edit and clean up (that is, refactor).

Scalability, on the other hand, is the ability of a system to handle a growing amount of work by adding resources to the system. Scalability can be measured over multiple dimensions, such as the following:

  • Administrative scalability: The ability to provide access to more organizations or users
  • Functional scalability: The ability to add new functionality without disrupting existing services
  • Geographic scalability: The ability to maintain effectiveness during expansion to a larger region
  • Load scalability: The ability to expand and contract to accommodate heavier or lighter loads
  • Generation scalability: The ability to scale by adopting new generations of components
  • Heterogeneous scalability: The ability to adopt components from different vendors

HA - High Available

High availability is a quality of a system or component that ensures a high level of operational performance for a given period of time. It is usually measured in “nines,” as an expression of the percentage of uptime in a given year. Here are some examples:

  • 90% uptime is “one nine”, which translates to 10% downtime (36.53 days per year)
  • 99.95% uptime is “three and a half nines”, or 4.38 hours of downtime per year
  • 99.999% uptime is “five nines”, or 5.26 minutes of downtime per year”

End-to-end latency has several components:

  • Application latency: How much time an application spends processing a request. Optimized code and programming language can improve application latency (for example, compiled code executes faster than interpreted code).
  • OS and TCP stack latency: How much time the operating system (OS) spends processing a request. Pick a specialized OS to improve it.
  • NIC latency: How much time a packet spends in the interface queue and how long it takes to put it onto a physical wire. Also known as the serialization delay, NIC latency is a function of the interface speed. It takes 93ms to push the 1500-byte packet into the wire on a 128KB ISDN interface, 0.12ms on a 100MB LAN, and just 0.5 µsec on a 25GB server interface.
  • Cable distance latency (propagation delay): A function of the speed of light, which is ~300 km/sec in a vacuum. In fiber media, it’s ~1.5 times less, so latency is ~5 microseconds/km. Therefore, it takes at least 100ms to get data to the opposite side of Earth (and 100ms to get a response).
  • Port-to-port latency within each network device along the path: It may be optimized by It may be optimized by using better performing hardware as well as by reducing the number of devices that a packet has to pass through (for example, use Clos fabric or Direct Server Return load balancing).

PS: Proactively prevent resource overload with rate-limiting mechanisms, which put a cap on how often someone can repeat an action within a certain timeframe. This can be applied to many processes:

REST API calls: Return an HTTP 429 “Too Many Requests” code to prevent API overuse and let the requestor know the system is busy at the moment.
Network traffic: Protect servers and network devices from overload during a distributed denial-of-service (DDoS) attack.
User interactions: Stop brute-force attacks (for example, do not allow more than three login attempts within 10 minutes).
Data protection: Do not allow frequent calls to extract data (aka web scraping).

Evaluate an application design and implementation considering maintainability

“Applications with poor code quality, undetected vulnerabilities, excessive technical complexity, poor documentation, excessive dead code, and so on, require additional maintenance effort. To avoid this, you can use a number of principles, approaches, and techniques that can help you develop maintainable software. These principles result in better outcomes during the design phase:

  • Implement modular design to make it easier to maintain individual components.
  • Implement object-oriented design to reduce complexity, add modularity, make it easier to implement changes.
  • Develop naming conventions.
  • Plan to use version control to keep code, tests, and documentation up to date and synchronized.”

Database

Relational databases (or SQL databases) are best suited for storing and querying structured data. Data is stored in tables, where columns (fields) describe data and rows (records) contain the actual data. Relational databases use fixed schemas on a per-table basis, and they are enforced for each record. SQL (Structured Query Language) is a programming language used to communicate with data stored in a relational database.

There are more types of database

Of course! Here are more detailed explanations and examples for each type of database:

  1. Relational Databases (RDBMS)

  2. Example: An online shopping site might use MySQL to store customer information, orders, and products. In this scenario, tables named Customers, Orders, and Products can be created, and relationships (like the one between orders and customers) can be established between these tables.

  3. NoSQL Databases

  4. Document-Based
    • Example: A blogging site could store each blog post as a document in MongoDB. These documents would contain details like the post title, content, author, and comments.
  5. Key-Value Based
    • Example: A website might store user session information in Redis for fast access. Here, the user's ID could be stored as the key, and the session info as the value.

  6. Graph-Based

    • Example: A social media platform could use Neo4j to store relationships and interactions between users. This facilitates queries like finding friends of friends.

  7. Object-Oriented Databases

  8. Example: A game might store in-game objects and characters in ObjectDB, preserving the object-oriented structure.

  9. In-Memory Databases

  10. Example: A finance application could store real-time stock market data in Redis to quickly present it to users.

  11. Hierarchical Databases

  12. Example: A company might want to store its employees in a hierarchical structure based on departments.

  13. Time-series Databases

  14. Example: A weather monitoring system could store data like temperature, humidity, and wind speed as a time series in InfluxDB.

  15. XML Databases

  16. Example: A library might store the metadata information of books in XML format in eXist-db.

  17. NewSQL Databases

  18. Example: A large e-commerce platform requiring global scaling could utilize Google Spanner.

Each of these examples illustrates the unique strengths and use cases of different database types. The choice of database often depends on the specific needs and requirements of the application or project.

Architectural Patterns

Monolithic

The term "monolithic application" refers to an architectural style of an application where all its components are combined into a single unit or module. In such applications, all functionalities are housed in one codebase, on a single system or platform. In contrast, other architectural approaches like microservices distribute different functionalities across separate modules or services.

Monolithic Application Example:

Let's say you're building an e-commerce website. This website has functionalities like product listing, order creation, payment processing, customer management, and inventory management.

In a Monolithic Approach: - All these functionalities are coded within a single application. - The application interacts with a single database. - The application's code, server, and other resources are hosted in one place. - When you want to make a change in the application, you often need to recompile and restart the entire application.

Advantages of this approach can include simplicity, less initial complexity, and often faster development cycles. However, for growing and scaling applications, this approach can pose challenges. For instance, an issue in one part of the application can affect the functioning of the entire application, or managing and updating large-scale applications can become more complex.

Therefore, when deciding when to use monolithic applications, one should consider the project's needs, scale, and long-term objectives.

Service-Oriented Architecture

Service-Oriented Architecture (SOA) is an architectural style in which software applications are constructed based on distinct service units with well-defined interfaces. These services can be reused across different applications and are designed to function in a distributed environment. They communicate with each other by passing data or coordinating an activity.

Key characteristics and concepts of SOA include:

  1. Loose Coupling: Services are independent units and changes in one service do not affect others. This allows for flexibility and easier maintenance.

  2. Reusability: Services are designed to be reused across multiple applications. This can lead to cost savings and a reduction in redundancy.

  3. Discoverability: Services can be discovered and invoked dynamically using a service registry or directory.

  4. Standardized Communication: Services communicate with standardized protocols, often web standards like HTTP, SOAP, or REST.

  5. Abstraction: Services hide the logic they encapsulate from the outside world.

  6. Statelessness: Ideally, services should be stateless, meaning they don’t retain user-specific data between sessions. Each request from a client contains all the information needed to process the request.

  7. Interoperability: Since services use standardized communication protocols, they can operate and communicate across different platforms and systems.

Example:

Consider an e-commerce platform:

  • The platform might have a Product Service that deals with product listings.
  • A separate Order Service handles customer orders.
  • A Payment Service processes payments.
  • A Shipping Service handles shipping details and tracking.

Each of these services can communicate with each other when needed. For example, when a customer places an order, the Order Service might communicate with the Payment Service to process the payment and then with the Shipping Service to handle the shipment.

One of the main benefits of SOA is that each service can be developed, deployed, and scaled independently. If the e-commerce platform needs to improve its payment processing capabilities, the Payment Service can be updated without affecting the Product, Order, or Shipping services.

However, SOA also comes with challenges, including the potential for increased network overhead and the complexity of managing and monitoring multiple services.

Microservices Architecture

Microservices architecture is a variant of the service-oriented architecture that organizes an application as a collection of loosely coupled services . Services are fine-grained units focused on doing just one thing, whereas with SOA, services are much bigger and complicated.

Microservice architecture allows for:

  1. Independence: Each microservice can be developed, deployed, and scaled independently. This can increase development speed and requires only the affected service to be restarted in case of errors.

  2. Flexibility: Different technologies, databases, and programming languages can be used for different services.

  3. Scalability: Only high-demand services need to be scaled, optimizing resource usage.

  4. Rapid Innovation: Teams can update or add new features to a specific microservice independently of other services.

  5. Resilience: If one service fails, it's possible for other services to continue working, increasing the overall resilience of the system.

  6. Fast Delivery and Integration: It's compatible with CI/CD (Continuous Integration/Continuous Delivery) approaches, facilitating the continuous and rapid deployment of updates and new features.

Example:

Let's reconsider an e-commerce platform. When using microservice architecture:

  • Product Service handles only functionalities related to products.
  • User Service deals with user accounts and authentication.
  • Order Service manages order creation and tracking.
  • Payment Service handles payments.

These services operate independently and communicate with each other over the network to exchange necessary information.

However, the microservice approach also has its challenges. Managing communication between services, handling service outages, and network latencies can add complexity to this architectural style. Therefore, before adopting a microservice architecture, the project's requirements and scale should be taken into account.

Event-Driven Architecture

Event-driven architecture (EDA) is an approach in software design where events or state changes trigger a system or application. In this architectural style, a specific action or process is executed as a result of a particular event occurring (e.g., a user clicking a button or a sensor exceeding a certain value).

Key characteristics of event-driven architecture include:

  1. Event Producers and Consumers: Components in the system either trigger an event (producers) or listen to and react to an event (consumers).

  2. Asynchronous Processing: Events are often processed asynchronously. This means that the triggering of an event can be handled in the background without blocking other operations.

  3. Dynamic Behavior: The system doesn't need to know in advance when a specific event will occur. This allows for dynamic and flexible system behavior.

  4. Loose Coupling: Event producers and consumers are typically independent of each other, resulting in a loose coupling between components. This facilitates independent development and modification of components within the system.

Event-driven architecture is commonly used in scenarios like real-time applications, complex workflows, user interfaces, and IoT (Internet of Things) systems. This architectural approach provides scalability, flexibility, and quick response times, but it also comes with challenges related to event ordering, state management, and error handling.

Event-driven architecture consists of two main topologies: mediator and broker. The mediator topology is commonly used when there is a need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used to chain events and responses together directly

Version Control Operations with Git