racecomputerservices-blog

[racecomputerservices-blog]

APIs are not enough – open banking is all about building an ecosystem. | Race Computer Services

APIs are not enough – open banking is all about building an ecosystem.by

Richard Race

July 20, 2018

We’ve all heard the mantra that every company is now a software company. But unlike some of the most successful software companies – including giants Google, Amazon, Netflix and Facebook – many businesses in other industries have yet to adopt the practices and platforms that can enable them to build better and more reliable software, faster.

Banks tend to be among that group. Leaders at financial institutions know they must change to stay competitive with startups, big tech companies and even retailers, not to mention emerging “super-apps” whose functions run the gamut from chat to purchase and bill payments. Close to 80 percent of operations leaders at North American banks believe that their bank’s existence will be threatened if they don’t update their technology to innovate faster and more efficiently, according to recent Accenture research. Evidence that digital transformation is on their minds can be found in EY’s Global Banking Outlook 2018, which notes that it is among 85 percent of all banks’ top three priorities this year.

Of course, it’s one thing to want a digitally mature operation, with integrated front-, middle- and back-office operations supported by data that flows across functions and geographies. Already having it is another. According to the EY study, 62 percent of global banks expect to reach digital maturity by 2020 but only 19 percent say that they currently are maturing or are already a digital leader in 2018.

One critical step to help reach digital transformation and maturity goals, and avoiding the consequences of not doing so, is to commit to the organizational culture of DevOps. In that respect, a bank will be following in the footsteps of the software giants, who not only embraced but propelled the practices behind continuous software delivery, test automation and run-what-you-build models. That’s the key to fast-tracking software release cycles for enhanced banking services – particularly mobile applications that put the user experience front and center to promote increasingly sticky customer connections – and being able to quickly identify and address issues.

The foundation of learning and constantly improving software in concert with feedback mechanisms is where competitive advantage lies. Admittedly, in the highly regulated financial services sphere, it’s not an easy leap to make. Also, practices in the banking industry that keep programmers, security and the operations working in their own silos, could slow progress. Organizations should push for a blended model within existing structures to do smaller releases more often and more quickly.

Jumping Off to DevOps

For those institutions that see DevOps as a leap worth making, it’s important to understand the technology pieces that will help keep the cultural change on track. Service mesh technologies such as Itsio serve DevOps approaches well. As the communications link between modular components, APIs coupled with service mesh facilitate the rapid delivery of new, easy-to-consume, more secure and scalable services without the need for operational centralization.

Container-based technology complements the move to microservice architecture, which are core to the development principles of building smaller and more modular applications. These technologies are often open source and polyglot, which support using the application runtime that makes the most sense for the team without the operational overhead.

To thrive in a world of rapid technology adoption by consumers it is important to not only respond quickly but also nurture the new API distribution channel of banking products and services.

Open Banking, supported by DevOps practices on an open cloud container platform, helps empower organizations to compete and respond to the new reality of rapid technology adoption.

Learn more about applying DevOps here.

[racecomputerservices-blog]

How REST API works natively in Red Hat CloudForms | Red Hat Linux Blog

Playing with REST API

by Richard Race

Overview

In this article, I will describe how REST API works natively in Red Hat CloudForms.

REST stands for Representational State Transfer. REST is a web standard based architecture and uses HTTP protocol for data communication. It revolves around resources where every component is a resource and is accessed by a common interface using HTTP standards method.

Red Hat CloudForms provides APIs to integrate external systems and initiate provisioning via CloudForms. In CloudForms, REST can be accessed by adding “/api” prefix to the URL.

https://<IP or hostname of appliance> /api/

How to play

In order to work with REST APIs, there are various REST API client tools  :

Internet Browser : Put a REST API call into the browser Address Bar

CURL :  Command line tool for HTTP client

curl -k -u username:password -X GET "Accept: application/json" https://<IP or hostname of appliance>/api/

Insomnia : A powerful REST API client with cookie management, code generation, authentication for Linux, Mac and Window etc.

HTTP Methods

Red Hat CloudForms API uses JSON (Javascript Object Notation Format) for data exchange format.  JSON is a commonly used format for data exchange and storing. The primary or most commonly used HTTP verbs are POST, GET, PUT, PATCH, OPTIONS, HEAD and DELETE. These correspond to create, read, update, delete (or CRUD) operations respectively.

MethodDEFINITIONExample (Using CURL)

GETReturn a specific resourcecurl -k -u user:password -X GET “Accept: application/json”

https://<IP>/api/providers/

POSTPerform an action on the resourcecurl -k –user user:password -i -X POST -H “Accept: application/json” -d ‘ { “type” : “ManageIQ::Providers::Redhat::InfraManager”, “name” : “RHEVM Provider”, “hostname” : “hostname of provider”, “ipaddress” : “IP”, “credentials” : { “userid” : “username”, “password” : “*****”}}’

https://<IP>/api/providers

PUTUpdate or replace  a resourcecurl -k –user username:password -i -X PUT -H “Accept: application/json”

-d ‘{ “name” : “updated service name” }’

http://<IP>/api/services/<service_id>

DELETEDelete a resourcecurl -k –user user:password -i -X DELETE -H “Accept: application/json”

https://<IP>/api/providers/<provider_id&gt

;

OPTIONSGet the metadatacurl -k –user username:password -X OPTIONS “Accept: application/json”

https://<IP>/api/providers/

HEADSame as GET, but transfers the status line and header section only.HEAD method is identical to GET except that the server MUST NOT return a message body in response.This method is often used for testing hypertext links for validity, accessibility, and recent modification.

PATCHUpdate or modify a resourcecurl -k –user username:password -i -X PATCH -H “Accept: application/json”

-d ‘[{ “action”: “edit”, “path”: “name”, “value”: “A new Service name” },{ “action”: “add”, “path”: “description”, “value”: “A Description for the new Service” },

{ “action”: “remove”, “path”: “display” }

]’

http://<IP>/api/services/<service_id>

Updating resources

As shown in the above table, there are a couple of ways to update attributes in a resource. You can update a resource with PUT or PATCH method. Now, the question is When to use PUT and When PATCH?

For Example

“When a client needs to replace an existing Resource entirely, they can use PUT. When they’re doing a partial update, they can use HTTP PATCH.”

For instance, when updating a single field of the Resource, sending the complete Resource representation might be cumbersome and utilizes a lot of unnecessary bandwidth. In such cases, the semantics of PATCH make a lot more sense.

How to authenticate REST APIs

REST APIs authentication can be done by two ways :

Basic Authentication : The most simple way to deal with authentication is to use HTTP basic authentication in which the username and password credentials are passed with each HTTP request.

Token Based Authentication: For multiple API calls to the appliance, it is recommended to use this approach. In this approach, client requests a token for the username and password. Then the token is used instead of username and password for each API call.

Acquiring a Token :

Request:

curl -k -u user:password -X GET "Accept: application/json" https://<IP>/api/auth

Response:

{"auth_token":"4cb1fb32508350796caf32c12808fee2","token_ttl":600,"expires_on":"2017-12-01T11:25:06Z"}

Query with Token

curl -k -i -X GET "Accept: application/json" -H “X-Auth-Token: “token” https://<IP>/api/hosts

Delete a Token

curl -k -i -X DELETE -H "Accept: application/json" -H "X-Auth-Token: 21fe54dd14dc89c219d62f651497a54" https://<IP>/api/auth

Moreover, the duration of token is about 10 minutes and we can change/modify the duration from CloudForms operational portal by navigating to Configuration -> Server -> Advanced -> api: -> token_ttl

Query Specification

Query specification identifies the controls available when querying collections. While querying, we can specify control attributes in the GET URL as value paris. There are three main techniques comes under query specifications. Let’s take a look on them.

Paging : In this capability, there are two attributes available as offset and limit. Offset means first item to return and limit means the number of items to return.

Sorting: In sorting, we can sort the attributes by order , options and attributes. For example: by specifying “sort_by=atr1,atr2” , “sort_order=asc or des”

Filtering:  This helps user to filter the data according to the use case. The syntax for filters is :

filter[]=attribute op value

where op means operators

Return Codes

Success :  200 : OK, 201 : Created, 202 : Accepted, 204 : No content

Client Errors: 400 : Bad Request, 401 : Unauthorized, 403 : Forbidden, 404 : Not Found, 415 : Unsupported Media Type

Server Errors: 500 : Internal Server error

Troubleshooting

A good place to troubleshoot is to look into standard log files under /var/www/miq/vmdb/log on the CloudForms appliance. All the api related logs are recorded under /var/www/miq/vmdb/log/api.log. In order to dig deeper, changing the level of log is much recommended. You can change the log level by navigating to Configuration → Server → Advanced → :level_api: debug.

Conclusion

I hope after reading this article you will get basic understanding about how CloudForms can be managed via REST API’s. You can find the full Rest API documentation here.

[racecomputerservices-blog]

Consider the security risks of your software

by Richard Race

Cybersecurity is an issue that hounds businesses of all types. Sometimes organizations invest in security software without realizing the risks that come with it. Here’s why identifying threats before buying cybersecurity products is paramount.

Uncover threats and vulnerabilities

Every business should evaluate the current state of its cybersecurity by running a risk assessment. Doing so is one of the easiest ways to identify, correct, and prevent security threats. After discovering potential issues, you should rate them based on probability of occurrence and potential impacts to your business.

Keep in mind that risk assessments are specific to every business and there is no one-size-fits-all approach for small business technology. It all depends on your line of business and operating environment. For instance, manufacturing companies and insurance groups have totally different applications to secure.

After tagging and ranking potential threats, you should identify which vulnerabilities need immediate attention and which ones can be addressed further down the line. For example, a web server running an unpatched operating system is probably a higher priority than a front desk computer that’s running a little slower than normal.

Tailor controls to risks

Instead of spending time and money evenly on all systems, it’s best that you focus on areas with high risk. You should address these issues immediately after an assessment, but also put plans in place to evaluate their risk profiles more often.

Assess existing products

Chances are, your organization has already spent a great deal of money on security products and their maintenance and support. By conducting risk assessments more often, you can improve the strategies you already have in place and uncover wasteful spending. You may discover that one outdated system merely needs to be upgraded and another needs to be ditched. Remember, your existing products were purchased to meet specific needs that may have changed immensely or disappeared altogether.

It’s much harder to overcome cybersecurity obstacles if you’re not regularly evaluating your IT infrastructure. Contact our experts for help conducting a comprehensive assessment today!

Published with permission from TechAdvisory.org.

Source.

[racecomputerservices-blog]

Empowering digital transformation in banking with Linux | Race Computer Services

With examples of more than a 20% decrease in branches over the past ten years at large North American banks, it’s no wonder that 42% of banks are well on their way to having digital become the primary distribution channel. In fact, 92% of global banks surveyed plan to begin their transformation to digital as the primary distribution channel in 2019.

Given efforts are underway, many banks are now wondering how to make this shift more efficient, repeatable, and even automated. Red Hat vice president and chief technology officer, Chris Wright, recently provided insights and described how banks are using technology to move beyond surviving digitization, instead creating environments that enable continual digital innovation.

Banks that are more agile are those that create a culture that embraces ongoing change. The fluidity to quickly adapt to the changing tides of customer demands requires open banking – the means by which banks engage in an open ecosystem to build new services – with both customers and partners. A big part of open banking is optimally using technology to build microservices rather than monolithic applications. Microservices are successfully crafted in an environment that permits reuse of these services as building blocks for the next app.

Simply put, “it’s all about the app,” according to Chris Wright, and creating apps that can be quickly developed and seamlessly deployed. Any-app, any-where can be successful when infrastructure software is consistent across platforms, eliminating brittle code that generates friction between cloud apps, virtualized apps, or apps held behind firewalls.

Banks look to reduce this friction because it slows the ability to respond, reuse, and re-invent apps as needed. A frictionless environment impacts developers using services to expedite app builds, and also cloud operators, who can automate operations across hybrid cloud environments. Perhaps most importantly a frictionless environment benefits consumers, who are presented with targeted and responsive apps because of optimized workload compute.

To get there, technology innovation trends are heavily relying on ways to separate app logic from everything else. In perpetual pursuit of excellence, organizations need to consider the interwoven dependencies of all digital technology audiences, namely:

Consumers – who are demanding more targeted, online experiences

IT Operations – who need more efficient ways to handle the increasing diversity of apps and their workloads

Developers – who want to continuously push the envelope for competitive differentiation

The good news is that you aren’t alone in this journey. Open source is the place where technology innovation is happening. Whether that’s serverless architecture, microservices, AI, blockchain, or other emerging uses, you can catch the waves of innovation rather than making your own. Tune in to Chris Wright’s “Digital Empowerment in Banking” e-event, now available on demand, to learn more.

[racecomputerservices-blog]

Red Hat OpenStack Platform 13 is here! - Rece computer service

Accelerate. Innovate. Empower.

In the digital economy, IT organizations can be expected to deliver services anytime, anywhere, and to any device. IT speed, agility, and innovation can be critical to help stay ahead of your competition. Red Hat OpenStack Platform lets you build an on-premise cloud environment designed to accelerate your business, innovate faster, and empower your IT teams.

Accelerate. Red Hat OpenStack Platform can help you accelerate IT activities and speed time to market for new products and services. Red Hat OpenStack Platform helps simplify application and service delivery using an automated self-service IT operating model, so you can provide users with more rapid access to resources. Using Red Hat OpenStack Platform, you can build an on-premises cloud architecture that can provide resource elasticity, scalability, and increased efficiency to launch new offerings faster.

Innovate. Red Hat OpenStack Platform enables you differentiate your business by helping to make new technologies more accessible without sacrificing current assets and operations. Red Hat’s open source development model combines faster-paced, cross-industry community innovation with production-grade hardening, integrations, support, and services. Red Hat OpenStack Platform is designed to provide an open and flexible cloud infrastructure ready for modern, containerized application operations while still supporting the traditional workloads your business relies on.

Empower. Red Hat OpenStack Platform helps your IT organization deliver new services with greater ease. Integrations with Red Hat’s open software stack let you build a more flexible and extensible foundation for modernization and digital operations. A large partner ecosystem helps you customize your environment with third-party products, with greater confidence that they will be interoperable and stable.

With Red Hat OpenStack Platform 13, Red Hat continues to bring together community-powered innovation with the stability, support, and services needed for production deployment. Red Hat OpenStack Platform 13 is a long-life release with up to three years of standard support and an additional, optional two years of extended life-cycle support (ELS). This release includes many features to help you adopt cloud technologies more easily and support digital transformation initiatives.

Fast forward upgrades

With both standard and long-life releases, Red Hat OpenStack Platform lets you choose when to implement new features in your cloud environment:

Upgrade every six months and benefit from one year of support on each release.

Upgrade every 18 months with long-life releases and benefit from 3 years of support on that release, with an optional ELS totalling to up to 5 years of support. Long life releases include innovations from all previous releases.

Now, with the fast forward upgrade feature, you can skip between long-life releases on an 18-month upgrade cadence. Fast forward upgrades fully containerize Red Hat OpenStack Platform deployment to simplify the process of upgrading between long-life releases. This means that customers who are currently using Red Hat OpenStack Platform 10 have an easier upgrade path to Red Hat OpenStack Platform 13—with fewer interruptions and no need for additional hardware.

Containerized OpenStack services

Red Hat OpenStack Platform now supports containerization of all OpenStack services. This means that OpenStack services can be independently managed, scaled, and maintained throughout their life cycle, giving you more control and flexibility. As a result, you can simplify service deployment and upgrades and allocate resources more quickly, efficiently, and at scale.

Red Hat stack integrations

The combination of Red Hat OpenStack Platform with Red Hat OpenShift provides a modern, container-based application development and deployment platform with a scalable hybrid cloud foundation. Kubernetes-based orchestration simplifies application portability across scalable hybrid environments, designed to provide a consistent, more seamless experience for developers, operations, and users.

Red Hat OpenStack Platform 13 delivers several new integrations with Red Hat OpenShift Container Platform:

Integration of openshift-ansible into Red Hat OpenStack Platform director eases troubleshooting and deployment.

Network integration using the Kuryr OpenStack project unifies network services between the two platforms, designed to eliminate the need for multiple network overlays and reduce performance and interoperability issues.

Load Balancing-as-a-Service with Octavia provides highly available cloud-scale load balancing for traditional or containerized workloads.

Additionally, support for the Open Virtual Networking (OVN) networking stack supplies consistency between Red Hat OpenStack Platform, Red Hat OpenShift, and Red Hat Virtualization.

Security features and compliance focus

Security and compliance are top concerns for organizations deploying clouds. Red Hat OpenStack Platform includes integrated security features to help protect your cloud environment. It encrypts control flows and, optionally, data stores and flows, enhancing the privacy and integrity of your data both at rest and in motion.

Red Hat OpenStack Platform 13 introduces several new, hardened security services designed to help further safeguard enterprise workloads:

Programmatic, API-driven secrets management through Barbican

Encrypted communications between OpenStack services using Transport Layer Security (TLS) and Secure Sockets Layer (SSL)

Cinder volume encryption and Glance image signing and verification

Additionally, Red Hat OpenStack Platform 13 can help your organization meet relevant technical and operational controls found in risk management frameworks globally. Red Hat can help support compliance guidance provided by government standards organizations, including:

The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.

Agence nationale de la sécurité des systèmes d’information (ANSSI) is the French national authority for cyber-defense and network and information security (NIS).

A updated security guide is also available to help you when deploying a cloud environment.

Storage and hyperconverged infrastructure options

Red Hat Ceph Storage provides unified, highly scalable, software-defined block, object, and file storage for Red Hat OpenStack Platform deployments and services. Integration between the two enables you to deploy, scale, and manage your storage back end just like your cloud infrastructure. New storage integrations included in Red Hat OpenStack Platform 13 give you more choice and flexibility. With support for the OpenStack Manila project, you can use the CephFS NFS file share as a service to better support applications using file storage. As a result, you can choose the type of storage for each workload, from a unified storage platform.

Red Hat Hyperconverged Infrastructure for Cloud combines Red Hat OpenStack Platform and Red Hat Ceph Storage into a single offering with a common life cycle and support. Both Red Hat OpenStack Platform compute and Red Hat Ceph Storage functions are run on the same host, enabling consolidation and efficiency gains. NFV use cases for Red Hat Hyperconverged Infrastructure for Cloud include:

Core datacenters

Central office datacenters

Edge and remote point of presence (POP) environments

Virtual radio access networks (vRAN)

Content delivery networks (CDN)

You can also add hyperconverged capabilities to your current Red Hat OpenStack Platform subscriptions using an add-on SKU.

Telecommunications optimizations

Red Hat OpenStack Platform 13 delivers new telecommunications-specific features that allow CSPs to build innovative, cloud-based network infrastructure more easily:

OpenDaylight integration lets you connect your OpenStack environment with the OpenDaylight software-defined networking (SDN) controller, giving it greater visibility into and control over OpenStack networking, utilization, and policies.

Real-time Kernel-based Virtual Machine (KVM) support designed to deliver ultra-low latency for performance-sensitive environments.

Open vSwitch (OVS) offload support (tech preview) lets you implement single root input/output virtualization (SR-IOV) to help reduce the performance impact of virtualization and deliver better performance for high IOPS applications.

Learn more

Red Hat OpenStack Platform combines community-powered innovation with enterprise-grade features and support to help your organization build a production-ready private cloud. With it, you can accelerate application and service delivery, innovate faster to differentiate your business, and empower your IT teams to support digital initiatives.

Learn more about Red Hat OpenStack Platform:

Red Hat OpenStack Platform product page

Online documentation

Free 60-day evaluation

[racecomputerservices-blog]

How to wipe data from your old smartphone

Our mobile phones contain some of our most private data. There are contact details, confidential business emails, financial information, and possibly even risqué pictures that you wouldn’t want falling into the wrong hands. Factory reset is one way to get rid of everything if you’re moving on from your old phone, but there are a few other things you must do first.

1. Encrypt your Android phone

You can make sure unauthorized personnel don’t have access to your data by encrypting it, making it virtually unreadable. Those who own a newer phone will likely have their data encrypted by default, but if you’re unsure, you need to double-check.

Simply go to the system settings in your phone and search for the Encryption option. The title and location will depend on which phone you’re using, but it should be easy to find. Once there, you’ll see whether your device is already encrypted or whether you should begin the encryption process. Keep in mind that it takes an hour or more to encrypt data, and you can’t use your device during that time.

2. Remove SIM card and storage cards

Now that your data is encrypted, remove your SIM card and external memory cards. Both are linked to your identity and contain sensitive information so it would be best if they never left your possession.

3. Perform a factory reset

You can now begin the actual data wiping process: Look for the Backup & reset section in your system settings where you will see the Factory data reset option. This is where you will remove data and accounts from your phone. It will ask you to either verify your fingerprint, or input your password, pattern, or PIN for protection before starting the process.

4. Sever ties to specific websites

The final step is to manually remove your old device from Google and other websites it is associated with. Just go to the site, choose your device, and remove it from the list of Trusted devices. And don’t forget your password manager and multi-device authentication apps; sign in to those and sever any connections there as well.

As long as you’ve followed these four handy steps, you’ll be safe when getting rid of an old mobile phone! But for those who are still anxious about their data, just give us a call. We’ll make sure to protect your files from prying eyes, and we’ll even provide valuable tips and tools to secure your new Android device.

Published with permission from TechAdvisory.org.

Source.